Area: sdk · streaming — gap · found via pm-triage reconcile of #554 (the part of #568 its fix does not cover)
Expected: an SDK that cannot interpret what the server is sending says so to the program — through error, a status, or a typed event — not only to a human watching a console.
Actual: a post-v2 SDK against a pre-v2 server connects, stays connected, and drops every row. In clients/ts/src/stream/sse.ts:612-620, with no event: schema seen _columns stays null, so each data frame hits _warnBounded("no-schema", …) and returns. _warnBounded (:248-257) only console.warns — at most three times per cause per connection, then one suppression line. No error callback, no status change. A liveQuery() is quieter still: its backfill goes over REST, so it paints its initial snapshot, reports status live, and then never updates. The reverse skew (older SDK, new server) yields data: undefined for every event.
Impact: silent data loss for any consumer who upgrades one side first — which docs/src/content/docs/sdk/streaming.md:127 calls "the normal deployment shape". Latent today only because published @wavehouse/sdk@0.1.1 and server v0.1.0 are both pre-v2; it goes live with the next release pair.
The behaviour is deliberate and already documented at streaming.md:124-128, which states outright that "a quiet console is not evidence the stream is healthy". That note is the argument for this issue rather than against it: the hazard is understood, and the only defence on offer is a person reading warnings.
Scope: a signal, not a version negotiation. #519 owns the stated compatibility policy; #568's option 3 (zip a legacy data object when no schema has been announced, for one release) is the other candidate shape.
Related: #568 (closed for our own docs site by pinning it to the published SDK — this is the residue), #548, #519, #543, #484, #517, #556
From the pm-triage routine's status reconcile of #553/#554/#555; validated by code-read against 681487aa on 2026-09-09.
Area: sdk · streaming — gap · found via pm-triage reconcile of #554 (the part of #568 its fix does not cover)
Expected: an SDK that cannot interpret what the server is sending says so to the program — through
error, a status, or a typed event — not only to a human watching a console.Actual: a post-v2 SDK against a pre-v2 server connects, stays connected, and drops every row. In
clients/ts/src/stream/sse.ts:612-620, with noevent: schemaseen_columnsstaysnull, so each data frame hits_warnBounded("no-schema", …)andreturns._warnBounded(:248-257) onlyconsole.warns — at most three times per cause per connection, then one suppression line. Noerrorcallback, no status change. AliveQuery()is quieter still: its backfill goes over REST, so it paints its initial snapshot, reports statuslive, and then never updates. The reverse skew (older SDK, new server) yieldsdata: undefinedfor every event.Impact: silent data loss for any consumer who upgrades one side first — which
docs/src/content/docs/sdk/streaming.md:127calls "the normal deployment shape". Latent today only because published@wavehouse/sdk@0.1.1and serverv0.1.0are both pre-v2; it goes live with the next release pair.The behaviour is deliberate and already documented at
streaming.md:124-128, which states outright that "a quiet console is not evidence the stream is healthy". That note is the argument for this issue rather than against it: the hazard is understood, and the only defence on offer is a person reading warnings.Scope: a signal, not a version negotiation. #519 owns the stated compatibility policy; #568's option 3 (zip a legacy
dataobject when no schema has been announced, for one release) is the other candidate shape.Related: #568 (closed for our own docs site by pinning it to the published SDK — this is the residue), #548, #519, #543, #484, #517, #556
From the pm-triage routine's status reconcile of #553/#554/#555; validated by code-read against
681487aaon 2026-09-09.