fix(ee): surface bridge load failures instead of silent fallback#39
Merged
fix(ee): surface bridge load failures instead of silent fallback#39
Conversation
Production deploy on Railway logs: [deployment] NUXT_DEPLOYMENT_PROFILE="managed" requires the Enterprise Edition (ee/) but the enterprise bridge did not load; falling back to 'community'. The local production build clearly bundles ee/ (chunks/_/index.mjs exports createEnterpriseBridge), so the failure is at runtime — most likely a native dependency (sharp / blurhash) failing to load for linux/amd64, or an import-side effect throwing during chunk instantiation. `loadEnterpriseBridge` was swallowing every error with `.catch(() => null)`, so the actual cause never reached the deploy logs. Replace the silent catch with explicit `console.error` (and a `console.info` on success + a `console.warn` for the missing-export branch). This is diagnostic output by design — if the bridge load is healthy, it's a single info line at boot; on failure, the operator sees the real error name, message, and stack. Once we have the real cause from the next Railway deploy, we'll either pin the platform binary in the Dockerfile or add a runtime guard around the failing native import. This commit is purely diagnostic — no functional change, no test impact.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
PR #37 deployed cleanly to staging, but the Railway logs show:
The local production build clearly bundles
ee/(the.output/server/chunks/_/index.mjschunk exportscreateEnterpriseBridge), so the failure is at runtime — mostlikely a native dependency (sharp / blurhash) failing to load
for
linux/amd64, or an import-side effect throwing during chunkinstantiation on Railway.
loadEnterpriseBridgewas swallowing every error with.catch(() => null), so the actual cause never reached the deploylogs. Without it, we can't tell whether
ee/is missing, thebundle path is wrong, or a top-level import is throwing.
What
console.error, includingthe error name + message + stack.
console.infoline on the success path so anoperator confirms the bridge loaded by reading the boot logs.
console.warnfor the missing-export branch (factoryfunction not present in the loaded module).
This is purely diagnostic — no functional change, no test impact.
Once we have the real cause from the next Railway deploy, the
follow-up PR will either pin a platform binary in the Dockerfile
or add a runtime guard around the failing native import.
Test plan
pnpm typecheck— cleanpnpm lint— 0 errors[ee] Enterprise bridge loaded successfully.(problem wentaway) or
[ee] Failed to import ee/enterprise: <real error>/
[ee] createEnterpriseBridge() threw at construction time: <real error>(real cause exposed).