Investigating hung/paused process while dynamically importing async module about deno

[bartlomieju]

Hey @maxmcd, thanks for the report. If this is reproducible in all versions past 1.40 then it's not related to V8 code cache (because the support for it shipped in v1.43). It looks like an event loop bug in deno_core.

Pinging @nathanwhit for help to pinpoint the problem here.

[maxmcd]

@nathanwhit fwiw, all of these commits fail for me.

[maxmcd]

Confirmed that my test passes in v1.40.5 but not in v1.41.0.

edit (😓): it looks like v1.41.0 and v1.41.1 work, but v1.41.2 does not.

[nathanwhit]

Hello! Like you mentioned, I also can't reproduce the issue with a simple module that imports the problematic module.

Could you share a bit about the test that's importing the problematic module?

Of course the source code would be ideal, but if it's closed source it would be useful to know some context about the code doing the import, for instance:

• Are there any other modules imported during this test? (if so, are they dynamic? are they being imported concurrently?)
• How is the test being run? (for instance, is the test module also dynamically imported by a test runner or something like that)

Really anything you can tell me about the test that hangs would be helpful 🙂

[maxmcd]

Hey @nathanwhit. I will keep working towards a minimal reproduction, hopefully I can figure it out.

I work at @val-town and this is during our test runs simulating user-defined code.

If you check out https://esm.town/guest.ts the const mod = await import(msg.data.entrypoint); line is a rough approximation of what is going on. That guest.ts is run by Deno and we import user-defined code at that line. With this test case, if I add a console.log statement after that import statement it is never reached.

so yes, this is a dynamic import, I believe it is the only import happening at that time. It is being run within another dynamic import, I think the library (and the test runner) import guest.ts with a dynamic import.

[maxmcd]

Ok, I was able to publicly replicate it on this branch: https://github.com/val-town/deno-http-worker/pull/11/files

If you download that repo and npm i you can run the test like so:

npx vitest run -t "replicate awaited"

You will see the logs:

stdout | src/DenoHTTPWorker.test.ts > DenoHTTPWorker > can replicate awaited promise bug
begin request

stdout | src/DenoHTTPWorker.test.ts > DenoHTTPWorker > can replicate awaited promise bug
[deno] start import

As the import begins and then never returns: https://github.com/val-town/deno-http-worker/blob/bcb46fdba1063f3d18646fb967f98499ef3b51bf/src/test/val-town.ts#L27-L29

If that's still too much complexity I'm happy to keep reducing this down to an even simpler reproduction.

[maxmcd]

Here are the commits to try

Excellent, I can work to check which ones work.

[nathanwhit]

Ok, I was able to publicly replicate it on this branch: https://github.com/val-town/deno-http-worker/pull/11/files

Oh awesome, I'll check it out!

(And sorry, deleted my previous comment right before you replied 😅)
Here's my previous comment for posterity:

---

Gotcha, thanks for the context!

I see you've also narrowed the regression down to v1.41.2 – would you mind trying out some canary builds from that timeframe to narrow this down even further? (for context, we upload canary versions of deno for every commit).

You can install a canary version with

deno upgrade --canary --version <commitHash>

then run your test suite, and then let me know which versions (if any) hang

Here are the commits to try:

• 736b91edd002ae34082c473b37249f9256a6ba32
• d9fa2dd5505a773ac2c8eb6ca2a8bbd237aca35d
• 9df917c0be620055c0d2eb53f76d4f1290d5e9e5
• 2d5b19277b483de64087822934d42fc3e09c1c24

[maxmcd]

@nathanwhit I believe this is the commit where my test starts failing: 736b91edd002ae34082c473b37249f9256a6ba32

Commit log here: https://github.com/denoland/deno/commits/main/?after=566adb7c0a0c0845e90a6e867a2c0ef5d2ada575+605

The commit right before it succeeds: 7ac0408

[nathanwhit]

Thanks for helping narrow this down and finding a minimal reproduction! It was super helpful in debugging this issue.

This should be fixed by denoland/deno_core#769 (which will land in deno in #24128).

[maxmcd]

Nice, thanks @nathanwhit! I just built against #24128 and my tests now pass!