search

module-federation / core

Module Federation is a concept that allows developers to share code and resources across multiple JavaScript applications
https://module-federation.io/
MIT License
1.52k stars 235 forks source link

[ Federation Runtime ]: The remote "app" is already registered. If you want to merge the remote, you can set "force: true". #2840

Open gyrgy opened 3 months ago

gyrgy commented 3 months ago

Describe the bug

Bug: [ Federation Runtime ]: The remote "app" is already registered

Issue Description

After upgrading to version 0.2.6 (and also present in 0.3.5) of the Module Federation Plugin, I'm encountering the following warning in the browser console that wasn't present in earlier versions:

[ Federation Runtime ]: The remote "app" is already registered. If you want to merge the remote, you can set "force: true".

This warning appears despite using build-time federation, where I wouldn't expect runtime-related messages.

Current Setup

I'm using build-time federation and am satisfied with this setup, except for this new warning.

Investigation Steps

  1. Initially suspected the DTS plugin might be causing the issue by attempting to reload the remote to fetch types.
  2. Disabled the DTS plugin in the Rspack config, but this led to new errors in the browser console: 
    main.js:59 WebSocket connection to 'ws://127.0.0.1:16322/?WEB_SOCKET_CONNECT_MAGIC_ID=1hpzW-zo2z-o8io-gfmV1-2cb1d82' failed: 
remoteEntryShell.js:60 WebSocket connection to 'ws://127.0.0.1:16322/?WEB_SOCKET_CONNECT_MAGIC_ID=1hpzW-zo2z-o8io-gfmV1-2cb1d82' failed: 
main.js:157 [ dynamic-remote-type-hints-plugin ] err: [object Event]
remoteEntryShell.js:158 [ dynamic-remote-type-hints-plugin ] err: [object Event]
remoteEntryApp.js:7076
  3. Even with the DTS plugin disabled, the original warning persists.

Simplified Test Case

I've created a simplified version of my production app structure to reproduce the issue:

Alternative Approach

I attempted to implement runtime federation. While this resolved the warning, it introduced new errors reported in Sentry:

[ Federation Runtime ]: Unable to use the container's...

Request for Assistance

I'd like to continue using the build-time plugin but need help resolving this warning. I'm open to contributing to the solution if needed.

Additional Information

Thank you for your time and assistance in resolving this issue.

Reproduction

https://github.com/gyrgy/mf-v035-test

Used Package Manager

npm

System Info

System:
    OS: macOS 13.4
    CPU: (8) arm64 Apple M2
    Memory: 109.91 MB / 24.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.7.1 - /opt/homebrew/bin/node
    npm: 10.5.0 - /opt/homebrew/bin/npm
    Watchman: 2024.03.25.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 127.0.6533.100
    Safari: 16.5

Validations

ScriptedAlchemy commented 2 months ago

The first warning about the runtime isn't a legitimate issue. Due to how we inject the v2 runtime, if multiple entries exist then the runtime initialization code is injected into each entry. Since the config hasn't actually altered it's not a concern. Im working on a PR that will get us off patching entries and instead using runtime modules to inject v2. Which will resolve this warning. It should not actually cause any interference. Next js has the same warning for example due to multi entries

gyrgy commented 2 months ago

Thank you for getting back to me with an explanation. I understand that even though the warning is there, it does not affect the shared contexts between the apps. I'm looking forward to the future versions where this warning will be resolved.

Regarding the other part of my report about the DTS plugin, if you'd like to move this to a separate issue, or if you're considering it as not a real problem, please feel free to close this issue. I'm happy to follow your guidance on how best to handle this part of the report.

Thank you again for your time and assistance.

gyrgy commented 2 months ago

For the DTS plugin, maybe something to add. If I have it turned on, my dev server just loosing the websocket connection with the browser and it's just keep trying to reconnect. Sometimes after 30s, sometimes a little later. Couldn't find a pattern, but I would say it might not be related to loading new pages or modules or any code change. It did also happen when I stayed on the same page and just waited. Couldn't debug it any further yet.

[webpack-dev-server] Disconnected! index.js:485 [webpack-dev-server] Trying to reconnect... main.js:7075 [webpack-dev-server] Disconnected! main.js:7075 [webpack-dev-server] Trying to reconnect... remoteEntryShell.js:7076 [webpack-dev-server] Disconnected! remoteEntryShell.js:7076

I'm not sure if it's related to the DTS plugin, or it's more likely an Rspack dev server issue or a mistake on my end, just wanted to add as it might be relevant.

ScriptedAlchemy commented 2 months ago

DTS should be seperate issue. The warning may be resolved in the next few released as i have found a solution to allow us to stop patching the entry chunks, but its complex to move so i have only implemented the first stages of the upgrade

gyrgy commented 2 months ago

Just tried with the version 0.6.0 and Rspack 1.0. Still there, but going to try with the upcoming releases. I appreciate the effort, thank you.

ScriptedAlchemy commented 1 month ago

They will slowly trickle down. Do you have multiple entrypoints?

shallow-alchemy commented 1 month ago

I get this error with multiple remotes listed in the consumer

ScriptedAlchemy commented 1 month ago

@shallow-alchemy do either of the remotes load the consumers "remote entry" ?

shallow-alchemy commented 1 month ago

Yeah. If I comment out the second one, the first one loads. And if I comment out first one, the second one loads.

But after looking at my configuration a bit more, I am trying have two different entries from the same end point locally. These end points diverge at build time in the pipeline. But locally, only one is used, so it gets duplicated.

I think that's the issue and maybe not really a bug. Should that be possible?

I'm migrating from a vite federated module set up. It worked on that set up

ScriptedAlchemy commented 1 month ago

If there are two "builds" or runtime from the same compilation on the page then they will have a collision due to chunk loading global stuff in webpack. Like 2 versions of remote or host runtime is from same build as remote runtime etc. Usually.

pkearney13 commented 1 month ago

I am having a similar issue. Does this mean that you can't have container A and container B depend on each other? Circular dependency?

ScriptedAlchemy commented 1 month ago

Should not be an issue. Supply repo

rull3211 commented 2 weeks ago

im also having problems with circular dependencies of host and remote. even tho the components they import from remote are pure components only

tags. When have such circular dependencies it seems that the apps start an import loop of death.

alltho im experiencing this problem on vite-plugin if that changes anything

Skjermbilde 2024-10-25 kl 08 10 57

ScriptedAlchemy commented 2 weeks ago

@rull3211 try it with webpack or rspack or rsbuild and see if the problem still exists

rull3211 commented 1 week ago

@ScriptedAlchemy i tested it with rspack and i dont get the same looping as here but still breaks the app. both apps are set up locally one on localhost:3175 and the other on localhost:3713 the app is just a spimle host/remote app setup with the quick start guide with one exposed testcomponent each

ScriptedAlchemy commented 1 week ago

Can you provide a repo I can look at

rull3211 commented 1 week ago

@ScriptedAlchemy here yopu go sorry tok a bit of time had to bootsrtap it https://github.com/rull3211/circularDeps this should successfully fail :) thanks for the superfast responses!

ScriptedAlchemy commented 1 week ago

Great. Will look on Monday. Have some friends visiting this weekend.

rull3211 commented 1 week ago

@ScriptedAlchemy no hurry i appreciate how responsive you guys are. best dev exp with a library sofar! so thanks for that and have a nice weekend