Repository navigation
Conversation
A STREAM_READINESS_TIMEOUT currently looks identical whether the upstream went fully silent (zero raw bytes) or stayed transport-alive (keepalive pings, no content event). Surface the distinction as pure telemetry: anyByteAt on the timeout result (null vs epoch-ms), the same value in an X-OmniRoute-Any-Byte-At response header for external tooling, and a grep-able log-line suffix. No behavior reads the signal. The stamp is strictly per-call — a module-level version let one stream's chunks mark concurrent streams as alive (observed in production), which the dedicated per-call tests pin.
This branch has not been deployed
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.
Problem and behavior
The stream-readiness watchdog reports one undifferentiated timeout: "no non-ping SSE event within the window". But two very different failure modes hide behind that message — a connection that never delivered any byte (dead path / silent upstream) versus first bytes (e.g. pings) flowing while content stalls before the first non-ping event (slow-but-alive upstream). When triaging TTFT incidents, operators currently cannot tell a network-side death from a provider-side stall without packet capture.
Changes
open-sse/utils/streamReadiness.ts— pure telemetry, no behavioral change:anyByteAt: a timestamp when any byte (pings included) was observed, or an explicitnullwhen the window expired with zero bytes ever — confirmed silence, not "unknown".Validation
tests/unit/stream-readiness-zero-byte-signal.test.ts(new, 5 tests) pins:nullon confirmed zero bytes; a timestamp once any byte arrives; the header carrier round-trip; per-call isolation between concurrent streams; and the default-path zero-change property. Adjacent stream-readiness suites (55 tests) green ·tscexit 0 · reponpm run lintexit 0 · changelog fragment18586-zero-byte-readiness-signal.mdincluded.Limitation: telemetry only — no retry/timeout decision consumes the signal in this PR; wiring it into policy (e.g. zero-byte = terminate-and-never-resend vs stall = rotate) is deliberately left for a follow-up once the observability lands.
Notes
release/v3.8.53(active release branch); aware of the 3.8.55v4-featureretarget policy.