📄 Clarification Needed in errorLoadRemote Docs — When is afterResolve Handling (and Fallback Manifest) Actually Required?

[AmazingJaze]

The current errorLoadRemote documentation includes this statement:

If you don't need to distinguish between error types, you can use a generic error handling solution:

I’m looking for guidance on how to determine whether I do or don’t need to distinguish between error types.

Right now the docs make it look like:

• If a host loads remotes using mf-manifest.json, you should handle the afterResolve lifecycle and return a fallback manifest.

• If you only care about a generic fallback, you can skip afterResolve handling.

But it’s unclear if that is the actual rule, especially for these cases:

My setup

• Using @module-federation/enhanced webpack plugin

• Build-time registration of remotes

• Only dynamic imports via loadRemote at runtime (no synchronous imports)

• No alternate containers to failover to (so any “fallback manifest” would just be a dummy placeholder)

• Share strategy: recently moved from version-first to loaded-first because of Module Federation crashes when it cannot fetch one of several remotes #3877

Testing so far shows that skipping afterResolve entirely, and returning an error fallback module in all cases, already fails gracefully for both remoteEntry.js and mf-manifest.json load failures.

Questions

1. Is the presence of mf-manifest.json remotes the only factor in deciding if afterResolve handling is required?

2. If there are no alternate containers, is there any real value in returning a dummy fallback manifest, or should the framework itself already fail gracefully without needing it?

3. Is it valid MF best practice to skip afterResolve entirely and just return a generic fallback module for all failures in errorLoadRemote?

I want to make sure I’m following intended best practices before removing afterResolve handling from my host, and this clarification in the docs would help other teams avoid unnecessary boilerplate or incorrect fallback manifest usage.