Module Federation crashes when it cannot fetch one of several remotes

[arivasnxt]

Describe the bug

When several remotes are declared in the bundler's configuration, and one of them cannot be fetched, the whole application crashes. It doesn't matter if the missing remote is not being imported, or if there is exception management with an error boundary.

This has impacted us especially since v0.7.3, when the default value for shareStrategy implied that all the remotes were fetched at startup instead of on demand.

We'd like to understand:

• Why the internal behavior of the plugin changed with v0.7.3. It's not clear to us why changing the value of shareStrategy defines whether to fetch the remotes at startup or on demand. If we understood it correctly, shareStrategy defines the share strategy for NPM packages. In this case, we are not sharing anything.
• If this crash is expected. We think the host application should be able to handle a graceful degradation instead of returning a total crash.

Reproduction

https://github.com/arivasnxt/mf-issue-greedy-fetching

Used Package Manager

npm

System Info

System:
    OS: macOS 15.5
    CPU: (12) arm64 Apple M3 Pro
    Memory: 554.45 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.16.0 - ~/.nvm/versions/node/v22.16.0/bin/node
    npm: 10.9.2 - ~/.nvm/versions/node/v22.16.0/bin/npm
  Browsers:
    Brave Browser: 135.1.77.97
    Chrome: 137.0.7151.120
    Safari: 18.5

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[ScriptedAlchemy]

doesnt the error load remote hook resolve this in a runtime plugin? @2heal1

[arivasnxt]

@ScriptedAlchemy as a clarification, we are registering the remotes in the plugin, and not using the runtime API.

[ScriptedAlchemy]

Yes but is the error catchable via federation runtime plugin. Your repo has no use of our runtimePlugins plugin option. This allows you rich control over handling of error cases

[arivasnxt]

Do you mean this? I guess we could create a custom runtime plugin that implements this hook, but it might be even more interesting to modify the default behavior of module federation so it doesn’t crash when one of the remotes can’t be found. Has this approach ever been explored?

[2heal1]

doesnt the error load remote hook resolve this in a runtime plugin? @2heal1

Yes, and here is thedoc for remote rendering error handle

[arivasnxt]

I'll try to implement an error handler based on the app example. I'll get back to you in a couple of days. Thanks!

[ScriptedAlchemy]

@arivasnxt can this be closed?

[arivasnxt]

I couldn't make this solution work. With the retry plugin I can set a fallback for the manifest, but that fallback does not work for the assets.

NonExinstingModule: "/path/to/non-existing-module/app-manifest.json"
FallbackModule: "/path/to/fallback-module/fallback-manifest.json"

After the retries the fallback manifest is successfully fetched, but the plugin tries to fetch the fallbackModule assets from the first module origin (e.g. /path/to/non-existing-module/fallback-chunk.js)

Could this be because I'm setting "auto" in both public paths?

[ScriptedAlchemy]

Use loadRemote or error load remote too?

[arivasnxt]

@ScriptedAlchemy I'm not using the runtime configuration, only the bundler configuration. I assume that if I did use it, I wouldn't face this issue, but I'd prefer to avoid that approach for my use case.

I've updated my playground branch to include both the official retry plugin and the fallback plugin shown in the docs example.

I tried using the retry plugin (see link above), but it only allowed me to redirect the manifest request, not the actual asset requests. Please note the host of the fallback requests in the following screenshot:

I also tried the fallback plugin, but couldn't get it to work as expected.

Let me restate the issue:
When one of the remotes is unavailable (network issue), I want to handle that error in the host app and adopt a graceful degradation strategy. I would expect this to be the plugin’s default behavior, rather than something each developer needs to implement themselves.

Would you be open to supporting this approach?

[ScriptedAlchemy]

Graceful fallback to what?
What function are you returning? What framework? Is it an object? Do you drill into the object? What module format?

Not trivial for me to know what your code does. This is why we give you runtime plugins.

Make a custom runtime plugin. Put console log in all hooks known. ErrorLoadRemote hook is what you want.

https://module-federation.io/guide/basic/runtime/runtime-hooks.html

[ScriptedAlchemy]

If you return a function to error load remote. It will use that as the module.

Check the runtime plugin in the nextjs mf plugin.