Cooperative termination mode: drain teardown instead of aborting

[clholgat]

Draft for discussion, not for merge. Updated to the cooperative-mode approach (replaces the earlier dispatch-guard version on this branch).

Problem

Aggressive teardown flips _isDisposed from another thread and force-terminates JS execution, aborting in-flight work and racing the JS thread. That's a large blast radius of teardown crashes / UB, and most of it is on host/session-scoped runtimes torn down on logout / scope-exit (not just workers).

Approach — a configurable mode, default cooperative

One flag on the runtime; cooperative mode drains instead of aborting:

• Host: makeJsThreadDispatchFunction no longer skips work just because _isDisposed is set. In-flight and already-queued JS-thread work runs (the context is still alive, since teardown is serialized after it on the serial queue), then teardown destroys the context and later calls are refused by the liveness check. This effectively restores the pre-aggressive ordering.
• Worker: terminate()/dtor skip requestExecutionTermination() and drain like self.close().

Set the flag false for aggressive termination (stops even frozen JS, at the cost of the teardown races), so the aggressive path stays available and can be rolled out again safely once the root cause is fully addressed.

Open question

This mitigates by reverting to cooperative behavior. The known trade is the original one: cooperative can't force-stop a genuinely frozen JS worker (it drains, so a busy loop won't tear down). A bounded wait-then-escalate would preserve the frozen-JS guarantee while keeping well-behaved teardown safe. Feedback welcome on whether to build that here or in the deeper fix.

Tests

bzl test //valdi:test_integration: new cooperativeTeardownDrainsInFlightWorkAggressiveSkipsIt (all 4 JS engines) asserts cooperative drains in-flight work and aggressive skips it; existing teardown and worker-termination tests stay green.

[github-actions]

📊 PR Size: size/M

Total changes: 141 lines (6 files)

Top files changed:

• valdi/src/valdi/runtime/JavaScript/JavaScriptRuntime.cpp: +36 -15
• valdi_core/test/cpp/DispatchQueue_tests.cpp: +38 -0
• valdi/test/integration/Runtime_tests.cpp: +26 -0
• valdi/src/valdi/runtime/JavaScript/JavaScriptRuntime.hpp: +9 -1
• valdi_core/src/valdi_core/cpp/Threading/ThreadedDispatchQueue.cpp: +8 -2
• valdi_core/src/valdi_core/cpp/Threading/GCDDispatchQueue.cpp: +5 -1

_{Size calculated as additions + deletions. Labels: XS (<10), S (<50), M (<250), L (<1000), XL (1000+)}

[github-actions]

⚠️ Bazel & CI Test Results

Test Suite	Result
macOS: C++ & Platform Tests	✅ success
Linux: Build & Export	✅ success
API Surface Check	✅ success
Snapshot Tests	✅ success
Valdi Smoke Tests	✅ success
valdi_web Integration Test	✅ success
Linux: C++ Tests	❌ failure
Linux: Module Tests	✅ success
Test Coverage Delta	✅ success
Linux: Build Compiler	✅ success
Linux: Registry Validation	✅ success
Linux: Hotreload Smoke	✅ success

Some tests failed. Please check the workflow logs for details.

🚀 Bazel remote cache is now enabled - future builds will be faster!

_{Workflow: Valdi CI}

[github-actions]

Sensitive Files Detected

⚠️ Core runtime — App-wide blast radius — touches the rendering core. Must be gated.

_{This is an automated notice. A maintainer will review after import.}