This field test was against Deno.
The issue was Deno #30652:
https://github.com/denoland/deno/issues/30652
The public PR is here:
https://github.com/denoland/deno/pull/34979
The reported problem involved Deno.stdin.readable and stream cancellation.
The useful diagnostic boundary was:
JavaScript readable stream cancellation → native stdin read operation → runtime resource lifecycle
That matters because Deno is not just an application framework.
Deno is a runtime.
A runtime sits underneath applications, scripts, CLIs, servers, test harnesses, automation, and developer tools. When a runtime API says a stream has been canceled, the underlying native resource path needs to agree.
The bug shape was subtle.
From the JavaScript side, reader.cancel() could resolve.
But the underlying stdin read operation could still remain alive.
That creates a mismatch between what the public API appears to say and what the runtime is still doing underneath.
In plain English:
the stream says it is canceled, but the native resource may still be keeping the process alive
That is a resource lifecycle boundary failure.
The repair is intentionally narrow.
It does not redesign Deno I/O.
It does not rewrite streams broadly.
It focuses on aligning Deno.stdin.readable cancellation with the resource-backed cancel/close path underneath it.
The patch changes stdin’s readable stream path so cancellation can properly reach the underlying resource lifecycle. It also adds a regression test that fails if the process hangs after canceling a pending stdin read.
The test creates a Deno.stdin.readable reader, starts a read, cancels the reader, and verifies that the process exits cleanly instead of staying alive until more stdin input arrives.
Local validation passed for:
- ./x fmt
- ./x lint
- focused integration regression for stdin readable cancellation
- git diff --check
A full Deno test suite run was not claimed.
Field Test #014
- Project: Deno
- Issue type: stdin readable stream cancellation / process hang
- Boundary: JavaScript stream cancellation vs native resource lifecycle
- Result: narrow runtime repair and regression test
- Status: public PR opened; awaiting maintainer review
This field test matters because it moves Scarab into a runtime-layer failure.
That is a different level from an application bug.
In an app, a bug usually affects that app.
In a runtime, a bug can affect anything built on top of that runtime.
The public API, the stream abstraction, the native operation, and the process lifecycle all have to agree. If one layer says “done” while another layer is still holding the process open, the system is no longer preserving its own truth.
That is exactly the kind of boundary Scarab is built to surface.
Not just:
did the code pass?
But:
does the public API truth match the runtime behavior underneath it?
This is another example of a small repair boundary with broad significance.
The fix does not need to be large to matter.
It needs to touch the place where the system stopped agreeing with itself.
Top comments (0)