sdk(stream): wire-version skew has no programmatic signal — a new SDK on an older server reports live and delivers nothing #577

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.