Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to fetch updated remote module code (caching issue?) #3119

Open
5 tasks done
arimus opened this issue Oct 25, 2024 · 7 comments
Open
5 tasks done

Unable to fetch updated remote module code (caching issue?) #3119

arimus opened this issue Oct 25, 2024 · 7 comments
Assignees

Comments

@arimus
Copy link

arimus commented Oct 25, 2024

Describe the bug

I have a host and a remote. The initial init + fetch works great, when a changes is made to the remote that host detects it with revalidate(), but a subsequent init + fetch seems to get the old code still.

Host: built with webpack, dynamic loading of module, using revalidate() to poll for changes that require an init + reload
Remote: running with webpack dev server

I'm not sure how to ensure the latest version of the code is fetched / the appropriate caches are cleared / etc.

p.s. is there no way for the host to get the HMR updates and trigger a reload off of that instead of polling or is the lack of a browser environment a deal breaker atm?

Reproduction

https://github.com/arimus/dynamic-remotes-node

Used Package Manager

npm

System Info

System:
    OS: macOS 14.4
    CPU: (10) x64 Apple M1 Pro
    Memory: 14.80 MB / 16.00 GB
    Shell: 5.2.21 - /opt/homebrew/bin/bash
  Binaries:
    Node: 20.12.0 - ~/.nvm/versions/node/v20.12.0/bin/node
    npm: 10.5.0 - ~/.nvm/versions/node/v20.12.0/bin/npm
    pnpm: 9.11.0 - ~/Library/pnpm/pnpm
    Watchman: 2024.08.05.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 130.0.6723.60
    Chrome Canary: 132.0.6795.0
    Edge: 130.0.2849.52
    Safari: 17.4
    Safari Technology Preview: 17.4

Validations

@2heal1
Copy link
Member

2heal1 commented Oct 25, 2024

Oh... i know the reason . Because runtime will catch the loaded remoteEntry/manifest in GLOBAL_LOADING_REMOTE_ENTRY . And this attr not be cleared , okay I will expose clearRuntimeCache methods to revalidate

@2heal1 2heal1 self-assigned this Oct 25, 2024
@arimus
Copy link
Author

arimus commented Oct 25, 2024

Just an FYI that this doesn't seems to be the case at first glance. I am dumping the GLOBAL_LOADING_REMOTE_ENTRY and it seems to be empty before and after an init() + loadRemote().

Also, tried a performReload() and that didn't seem to do help either. It has the logic in there to clear GLOBAL_LOADING_REMOTE_ENTRY as well a clear the module cache.

@arimus
Copy link
Author

arimus commented Oct 28, 2024

Let me know if you guys have any other ideas on why this isn't working

@2heal1
Copy link
Member

2heal1 commented Oct 29, 2024

Because the bundler bundle GLOBAL_LOADING_REMOTE_ENTRY into share object closure , so it can not access via globalThis , it should be solved by providing a internal remove cache method
image

@arimus
Copy link
Author

arimus commented Oct 29, 2024

Ahhhhh...that makes sense. I'll test when you guys are able to make this somehow trigger-able externally.

@MadaraUchiha-314
Copy link
Contributor

MadaraUchiha-314 commented Oct 31, 2024

@ScriptedAlchemy @2heal1 I am running into this same issue

Here's a minimal reproducible example: https://github.com/MadaraUchiha-314/nailsmith

For me the issue is with the uniqueKey that's being generated:

Screenshot 2024-10-31 at 1 30 33 PM

Since my remote doesn't have a unique hash in the URL (which is a requirement for local development), it treats it as the same remote making hot reloading not work.

When can we expect a fix for this ? Should I raise a PR ?

@2heal1
Copy link
Member

2heal1 commented Nov 1, 2024

@arimus @MadaraUchiha-314 Yeah , i will fix it next Wednesday by providing a clearCache api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants