deno

14deb460 - chore: regression test for KV panic on uncaught error with listenQueue (#34553)

chore: regression test for KV panic on uncaught error with listenQueue (#34553) ## Summary Locks in the fix for [denoland/deno#20464](https://github.com/denoland/deno/issues/20464): opening a KV, attaching `listenQueue()` without `await`, and then hitting an uncaught error on the main task used to panic the runtime with `Attempted to use a closed database` (at `ext/kv/sqlite.rs:440` in 1.36.4) while the queue's dequeue loop raced against the dropped SQLite connection. The 2023 reporter triggered it from Fresh's `dev.ts` (a `ReferenceError: Cannot access 'manifest' before initialization` followed by `await start(manifest, config)`), but the underlying race was generic to any uncaught error on the main task while `listenQueue` was outstanding. The runtime now unwinds cleanly: the JS error surfaces, the process exits non-zero, and there is no panic. This spec test pins that behavior so the property isn't lost silently if the queue/close ordering is refactored again. The new spec mirrors the reporter's setup: open `Deno.openKv(":memory:")`, fire `kv.listenQueue(() => {})` without `await`, log `Listening for messages...`, then `throw new Error(...)`. The test asserts exit code 1 and the JS error in stderr — any future regression that brings back the panic would change exit status and add a `Deno has panicked` block to the output. ## Test plan - [x] `target/debug/deps/specs-* kv_listen_queue_uncaught_error` passes locally - [x] Verified `deno run --watch` against the same reproducer prints the JS error and waits for a file change with no panic / no backtrace Closes denoland/orchid#299 Co-authored-by: divybot <divybot@users.noreply.github.com> Co-authored-by: Divy Srivastava <me@littledivy.com>