Soft‑fail support for missing manifest.json to avoid persistent downtime when a remote service is offline

[Guibod]

Description

While adopting the new manifest.json approach for declaring remotes in @module-federation/core, I've observed that if a remote’s manifest is unavailable (e.g. due to the micro‑service being down or undergoing deployment), the host application fails to bootstrap entirely.
This triggers continuous downtime even though only one micro‑service is affected.

Previously, with remoteEntry.js, the host would still launch—logging the error but continuing, resulting in a degraded yet functional app.
With manifest.json, the behavior is stricter and more fragile.

Steps to Reproduce

Configure a remote via manifest.json:

remotes: [
  { name: 'remoteA', entry: 'http://host:port/mf-manifest.json' },
  // many other remotes
]

Ensure that mf-manifest.json is not served (e.g. service is down).

Start the host → it errors out and crashes during bootstrap due to "failed to fetch manifest".

Problem

This lack of fallback causes the entire host app to crash because of a single remote’s downtime, even if that remote's functionality isn't critical at the moment.

Question

Is this considered a real issue or an expected trade-off with the manifest-based remote loading approach?

Is there a recommended way to gracefully handle the absence of a manifest.json (e.g. fallback or delayed resolution)?

Is this strict failure behavior intentional? And if so, does it mean I should stick with remoteEntry.js for use cases where resilience to remote downtime is critical?

[ScriptedAlchemy]

search git issues, i comment on this.
Also try using loaded-first as the shareStrategy