fix(runtime-core): route manifest validation errors through errorLoadRemote#4654
fix(runtime-core): route manifest validation errors through errorLoadRemote#4654sessa wants to merge 3 commits intomodule-federation:mainfrom
Conversation
…Remote Two error paths in the snapshot plugin bypass `errorLoadRemote`, causing unrecoverable crashes when a remote's manifest is malformed or its remoteEntry URL is missing. Consumers that register an `errorLoadRemote` handler expect all remote-loading failures to flow through the hook so they can provide graceful fallbacks (e.g. rendering a shell without the failed micro-frontend). **Bug 1 — manifest shape validation (SnapshotHandler.getManifestJson):** The `assert(metaData && exposes && shared)` sat outside the `try/catch` that emits `errorLoadRemote`. When a manifest fetched successfully as valid JSON but was missing required fields, the assert threw directly, bypassing the hook entirely. Fix: move the assert inside the `try` block so the `catch` emits `errorLoadRemote` with `lifecycle: 'afterResolve'`, giving plugins a chance to supply a fallback manifest. **Bug 2 — missing remoteEntry URL (snapshotPlugin.afterResolve):** `assignRemoteInfo` calls `error(RUNTIME_011)` which throws when `remoteEntryInfo.url` is empty. This throw was unguarded in the `afterResolve` hook, so it propagated as an uncaught waterfall error instead of routing through `errorLoadRemote`. Fix: wrap `assignRemoteInfo` in a try/catch that emits `errorLoadRemote` with `lifecycle: 'afterResolve'`. If the hook returns a truthy value the error is considered handled and the host continues; otherwise the original error is re-thrown. Made-with: Cursor
✅ Deploy Preview for module-federation-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f034b5e95
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| assert( | ||
| manifestJson.metaData && manifestJson.exposes && manifestJson.shared, | ||
| `"${manifestUrl}" is not a valid federation manifest for remote "${moduleInfo.name}". Missing required fields: ${[!manifestJson.metaData && 'metaData', !manifestJson.exposes && 'exposes', !manifestJson.shared && 'shared'].filter(Boolean).join(', ')}.`, | ||
| ); |
There was a problem hiding this comment.
In getManifestJson, moving the required-field assert entirely inside the fetch try means values returned from errorLoadRemote are now accepted without shape checks. If a plugin returns a non-manifest payload (for example an args object), it gets treated as manifestJson and then fails later in generateSnapshotFromManifest, outside this recovery block, which bypasses the intended afterResolve handling and produces a harder-to-recover error path. Re-validate manifestJson after the catch before caching/using it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 2c5cecf. Added a post-catch assert that re-validates manifestJson after the errorLoadRemote failover, ensuring payloads returned by plugins are checked for required fields (metaData, exposes, shared) before being cached or passed to generateSnapshotFromManifest. Also added a test covering this case.
| if (!failOver) { | ||
| throw assignError; | ||
| } | ||
|
|
||
| return args; |
There was a problem hiding this comment.
When assignRemoteInfo throws, this block treats any truthy errorLoadRemote return as handled, but then returns the original args without applying the failover result. That suppresses the original error while leaving remoteInfo unchanged, so loading continues with invalid remote entry metadata and fails later in a different lifecycle. If afterResolve failover is supported here, its return value needs to be consumed to repair state; otherwise the original error should be rethrown.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 2c5cecf. The failover is now passed to assignRemoteInfo(remoteInfo, failOver as ModuleInfo) so the returned snapshot is actually applied to repair remoteInfo state. If the failover itself is invalid, assignRemoteInfo will throw and the original error propagation is preserved.
Update errorLoadRemote docs to reflect that afterResolve lifecycle now also catches manifest validation errors (missing metaData, exposes, or shared fields), not just network failures. Update ZH runtime-hooks to include the lifecycle field and descriptions matching the EN version. Made-with: Cursor
Address review feedback: - Re-validate manifestJson after errorLoadRemote returns to reject invalid failover payloads before they reach generateSnapshotFromManifest - Apply failover snapshot via assignRemoteInfo instead of discarding it - Add test covering invalid failover rejection Made-with: Cursor
|
hey , can you help resolve conflicts |
2 participants
Description
Moves the manifest validation
assert(checking formetaData,exposes, andsharedfields) inside the existingtry/catchblock inSnapshotHandler, so that validation failures are routed through theerrorLoadRemotelifecycle hook instead of throwing an uncatchable error.Additionally wraps the
assignRemoteInfocall in the snapshot plugin with error handling that also emitserrorLoadRemote, giving plugin authors a consistent recovery point for both fetch failures and malformed manifest payloads.Related Issue
Manifest validation errors previously bypassed
errorLoadRemote, making it impossible for plugins to recover from or handle invalid manifests gracefully.Types of changes
Checklist