Bug: Web workers appear to reuse same module cache

[dev-nicolaos]

This appears to be a regression (was previously reported in #6116). My understanding is that each web worker is supposed to its own separate module cache that is separate from the one used for the main thread and those used for other workers.

Web Worker References

• Deno Manual
• MDN

Environment

OS: Windows 11 Home Version 22H2

Observed in Deno v1.27.0

Steps to reproduce

I initially observed this in a more complicated example and provide that context if desired, but for simplicity sake I reusing the steps from #6116 as I believe they illustrate the same issue and is much simpler.

1. Create a file script.ts with the content console.log('hello').

2. Create another file main.ts with the following content:

while(true) {
  const worker = new Worker(new URL("./script.ts", import.meta.url).href, { type: "module"});
  await new Promise(resolve => setTimeout(resolve, 1000))
  worker.terminate()
}

3. Run this command: deno run --allow-read main.ts.

4. Modify the content of script.ts to console.log('bye') and save it.

Expected behavior

The subsequent log of deno run --allow-read main.ts should be bye.

Observed behavior

After step 4, the subsequent log of deno run --allow-read main.ts is still hello.

Notes

Testing with JS files yielded the same result. I also tried using self.close in the worker rather than worker.terminate and again got the same result.

[bartlomieju]

I believe this behavior matches what browsers do - once you fetch the source once it won't be fetched again in the same session (or until cache expires). If you really want to reload the source you can add a query param that will cache-bust, something like: import.meta.resolve(./script.ts?cache=${new Date().getTime()})

[bartlomieju]

I'm gonna close this issue for now, I suggest to use the above solution if you really need to reload sources in-process.

[NyanHelsing]

I dont think that adding a date time is a valid solution because in trying this it still loads the cached module. the only way I can seem to bust the cache is by starting a new process or by doing this:

Deno[Deno.internal].core.ops.op_create_worker({ hasSourceCode: true, name: "hello", sourceCode: await Deno.readTextFile("./my-script.ts"), permissions: {}, workerType: "module", specifier: "file:///dev/null"})

...which is a nightmare because I can't easily post messages to it or anything because i haven't bothered to read how passed messages get serialized and also probably shouldn't be possible because type === "module" && hasSourceCode === true???

[NyanHelsing]

@bartlomieju Looking deeper I seem to have found the culprit is the way Deno is calculating module specifiers.

see my patch here: https://github.com/denoland/deno/pull/17755/files

[NyanHelsing]

@bartlomieju Looking deeper I seem to have found the culprit is the way Deno is calculating module specifiers.

see my patch here: https://github.com/denoland/deno/pull/17755/files

mmmm no that doesn't seem right..... 😮‍💨
I think for me workaround by reading file into a blob url gets me pretty much what I want. gotta figure out how to make that work with ts now tho, probably emit()

[vfssantos]

@bartlomieju , does this means that Deno's web worker will keep the module in memory even after it's terminated, and won't free up the memory until the main session is ended?