Pump V8's foreground task queue so async WebAssembly settles

[bkaradzic-microsoft]

V8 finishes asynchronous WebAssembly compilation on a background thread and then posts a foreground task to settle the promise on the isolate thread. AppRuntime_JSI already ran those via TaskRunnerAdapter; the direct-V8 path dropped them, so WebAssembly.compile / instantiate / instantiateStreaming never resolved or rejected. Synchronous new WebAssembly.Module was unaffected, which made this look like a hang rather than a failure.

Foreground posts now go through a DispatchingTaskRunner that calls v8::Task::Run on AppRuntime's dispatcher (Chromium's V8ForegroundTaskRunner model). Delayed posts use DeadlineScheduler, the native queue also behind setTimeout / setInterval. PumpMessageLoop and the no-op wake are gone.

All three new tests time out at 30s without this change and pass in ~10ms with it.

[Copilot]

Pull request overview

This PR fixes a hang in the direct-V8 runtime path where V8 foreground tasks (notably those used to settle async WebAssembly compilation promises) were never pumped, preventing WebAssembly.compile/instantiate/*Streaming from resolving or rejecting.

Changes:

• Wraps V8’s default platform with a DispatchingPlatform/WakingTaskRunner that nudges the app dispatcher when foreground tasks are posted.
• Updates AppRuntime::DrainMicrotasks (V8) to pump V8’s foreground task queue using v8::platform::PumpMessageLoop(..., kDoNotWait).
• Adds unit tests covering async WebAssembly compile/instantiate settling and rejection behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Tests/UnitTests/Scripts/tests.ts	Adds WebAssembly async promise-settling and rejection tests to prevent regressions.
Core/AppRuntime/Source/AppRuntime_V8.cpp	Introduces a dispatch-waking V8 platform wrapper and pumps V8’s foreground queue during DrainMicrotasks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[bkaradzic-microsoft]

CI found two things my local V8 build could not, both fixed in fda5f78.

1. Android build break. Android builds against V8 11.0, desktop against 11.9. DispatchingPlatform forwarded the entire v8::Platform interface, and five of those members simply do not exist in 11.0: GetThreadIsolatedAllocator, CreateBlockingScope, CurrentClockTimeMilliseconds, CurrentClockTimeMillisecondsHighResolution, and the TaskPriority overload of GetForegroundTaskRunner. Overriding a method the base class does not declare is a hard error, hence no type named 'ThreadIsolatedAllocator' in namespace 'v8' and friends.

Rather than guess version thresholds I pulled the Android package and read its v8-version.h (11.0.226.16) and v8-platform.h directly, so the gating matches the header rather than my memory of when each member landed. I also checked all nine of 11.0's pure virtuals are still overridden -- that is the part that would silently break the build again. Where a member is gated out we fall back to v8::Platform's own default, which is benign for each: a null allocator, a null blocking scope, and clock values derived from CurrentClockTimeMillis.

2. The WebAssembly tests ran on every engine. The fix is V8-only, so JSC/Chakra/Hermes/QuickJS did not fail -- they hung, three times 30s apiece. Those engines' runtimes have the same class of gap; fixing them is a separate change.

I added a hostEngine global mirroring the existing hostPlatform and scoped the suite with a beforeEach skip. Verified both directions rather than just the happy path:

engine	result
V8	220 passing, tests execute
Chakra	217 passing, 3 pending, 11.7s (was ~90s of timeouts)

Worth noting the earlier green runs on this PR were queue artifacts -- this was the first run that actually built Android, so the breakage was there from the start rather than introduced by the last push.

[bkaradzic-microsoft]

Follow-up: that push missed a second definition site, now folded in (the commit above is amended to 4a5d722).

Android does not build the UnitTests target -- it builds a separate UnitTestsJNI library from its own CMakeLists.txt, which compiles the same Shared.cpp. So adding JSRUNTIMEHOST_ENGINE only to UnitTests left the JNI target without it: error: use of undeclared identifier 'JSRUNTIMEHOST_ENGINE', which broke all three Android legs including JSC and QuickJS.

One thing worth flagging while I was in there: JSRUNTIMEHOST_PLATFORM is passed to the JNI target as -DJSRUNTIMEHOST_PLATFORM=\"\" -- empty. It is set as an ordinary variable inside the root project's scope, and add_subdirectory does not propagate that back up to the JNI CMakeLists.txt, so hostPlatform is "" on Android today. NAPI_JAVASCRIPT_ENGINE does not have this problem because gradle passes it on the CMake command line, making it a cache variable visible in every scope, so hostEngine resolves correctly. I have left the pre-existing hostPlatform quirk alone as it is unrelated to this PR, but it is a live bug for any test that gates on hostPlatform on Android.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

Concerns inline.