module federation: if a chunk fails on first import, subsequent imports do not refetch the chunk

[mbest]

Bug report

What is the current behavior?

Using https://github.com/module-federation/core/blob/main/packages/utilities/src/utils/importRemote.ts, and the import fails with "Loading chunk xxx failed", a subsequent call to importRemote with the same module will not try to reload the missing chunk.

Stepping through the code, it appears that this is because where a chunk fails to load, the entry in startedInstallModules is still set to true, and so it isn't later reloaded.

I tested with reseting the value in startedInstallModules to false. In this case, the chunk is loaded, but then I ran into another problem. In "bootstrap", it finds a "cached module" and returns it even though its "loaded" flag is false. Turning on strictModuleErrorHandling doesn't solve it since it just throws the previous exception. But turning on strictModuleExceptionHandling does fix it since it causes the module to be initialized again.

What is the expected behavior?

There should be a way to reload a module (and dependencies) that previously failed to completely load.

There was a comment about match how import works for ESM. I found the following on MDN:

Module namespace object caching only applies to modules that are loaded and linked successfully. A module is imported in three steps: loading (fetching the module), linking (mostly, parsing the module), and evaluating (executing the parsed code). Only evaluation failures are cached; if a module fails to load or link, the next import may try to load and link the module again. The browser may or may not cache the result of the fetch operation, but it should follow typical HTTP semantics, so handling such network failures should not be different from handling fetch() failures.

Importantly, it states that module loading failures should not be cached, but currently webpack does "cache" module loading failures, both in that it does not retry loading (because of startedInstallModules) and that because loading failures are deferred to module evaluation, those modules don't get re-evaluated after the module is reloaded.

Other relevant information:
webpack version: 5.98.0
Node.js version: 18.20.7
Operating System: Windows 11
Additional tools:

[syed-yaga]

Wrap importRemote in a retry function that waits and retries if a chunk fails

[mbest]

If you read my issue report, that's exactly what doesn't work.

[alexander-akait]

Yes, you need an extra code for this logic, we try to be align how import works in esm, and there is no try it load again for import(), if we change it some code like try/catch can stop work or generates extra requests that will be bad

[alexander-akait]

@mbest Can you provide reproducible test repo if you think it is a bug?

[mbest]

Retrying used to work before #16625. Using webpack 5.89.0, chunks that previously failed to load will be reloaded on a second call to importRemote. To fully make retrying work, you also need to set strictModuleExceptionHandling so that the previously failed modules get reinitialized.

Starting with 5.90.0 (with #16625 included), previously failed chunks don't get reloaded.

I'm not sure how to create a test repo.

[alexander-akait]

Just provide steps to reproduce your problem, I need to see your code and structure to understand why now it doesn't work for you

[mbest]

I've tried to clarify and add some more details to the description above. To try to create a repro, do you have any basic starting point I can use?

[alexander-akait]

Just get your repo - remove any sensitive code (and unnecessary code too) and provide steps in readme (or describe them here and provide link on the github reproducible test repo) how I can see your problem. Problems come in different forms, so there is no universal hint on how to demonstrate it, but it's easier to start from what you already have.

I would also add that if the error was common and many people suffered from it, you would most likely have already seen an issue/discussion (with a lot of 👍), so I recommend double checking your own code first, see what webpack generates and try to debug it, most often it allows you to find the problem faster and better, including allowing you to determine what is wrong on your side (with code/configuration/logic).

To be honestly I don't think strictModuleErrorHandling is directly related to your problem. This option may be involved in this one way or another, but it's clearly not a direct problem.