Fix/streamable http fixes - #272
Merged
Merged
Conversation
- A stream cut by the far end reported the request it was carrying, and that request was picked up again — over a standalone stream, which this revision does not serve - The refusal that came back was read as a fact about streams rather than about the request, so the request stayed outstanding and its subscription went on being held with nobody at either end of it - Nothing can pick one up in this era: no event ids to carry on from and no stream to carry on over, so a cut stream is the end of what it was carrying, said through the path that also lets go of a subscription - The local case never showed this: ending one takes its request away before the connection closes, so nothing was left to be resumed
- Finding a free port ignored whether the bind or the listen worked, so a machine where that is what is wrong reported only a zero, and a caller had nothing to pass on - Both interop programs are TypeScript run straight by node, which node can only do from 22.6 and only unasked from 23.6; in between it has to be asked, and a node that is not asked fails on the first line - Asked for by version now, so it works where it can and says so where it cannot — rather than exiting instantly and looking, from the outside, exactly like a server that started and never listened
- Every scenario failed the same way: ten seconds of nothing and a bare false, which says only that something is wrong somewhere - What it wrote was being discarded on the grounds that it is nobody's business unless something goes wrong — but nothing said it when something did - Kept and reported now: the port, whether it was still running or had exited, its code, and its own account of itself - A node that cannot run these programs is a skip that names the version, rather than six identical timeouts
) - Waiting for a child drained its pipe to the end before looking at the clock, and the end of a pipe is every write end closing — which for a child that is still running has not happened - So the wait was for the child to exit, inside the call whose whole purpose is not to wait longer than it was told, and the caller that asks exactly when a peer is running and not yet serving would have hung on the question - Read for what is there, reap if it has gone, check the clock, round again — and what it wrote is kept whichever of the last two settles it - A child being told to go is drained too, since one that has to be killed is one somebody will want an account of
- The other direction asks before it starts and skips; this one left the question to the run itself and reported four failures, all of them meaning the same thing — that this machine cannot host the test - Asked where everything else this needs is asked, so it says it once - Covered directly: the two harness tests need no node at all, so they run wherever this is built
- Waiting reported the same thing for both — nothing — so callers guessed from whether it was running just beforehand, and a child that had already died was still running to anything that had not reaped it - So a peer that crashed on startup was reported as still running, which is the one case these diagnostics exist for and the answer they most need to give - Three outcomes now, named where the reaping happens: exited with a code, killed by a signal, or still going — and the signal is named - Whatever it wrote before it died is still kept and still reported
caleb2h
approved these changes
Aug 24, 2026
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.