test: prove the light-mode claim on two sockets, and stop a codec swap in silence #104

Merged

yuris merged 1 commit from light-two-client into main

2026-08-22 03:04:16 +00:00

yuris commented

2026-08-22 02:58:38 +00:00

Owner

Closes the last actionable item on #77.

The gap

smoke.script said so itself, in the header: "Proving light mode is honoured for OTHER clients' transactions still needs a second connection and is not attempted here." Phase 1 only ever checked the caller's own transaction. The cross-client behaviour was established by a hand-run four-observer measurement and written into the wiki as fact, with nothing re-checking it.

Phase 8

v1 only — v2 has no light mode to produce a light frame. An ordinary observer, no light flag anywhere, watches a commit caused by the main socket. One commit, two sockets, asserted to differ:

SMOKE: PHASE8 OK same commit, two shapes: observer got TransactionUpdateLight
(foreign request_id=14), caller got a full TransactionUpdate for reducer "send_message"

Both halves against the same transaction, because either alone is consistent with a server that ignores light entirely. Failable by construction — with the observer making the call instead:

SMOKE: FAIL the observer received a FULL update for another socket's commit

The observer is closed before phase 6, which times a frame budget and would otherwise pay for a second socket decoding its own copy of every insert.

The defect it found

stdb.protocol is pure and holds its JSON codec in a module local. connection.new injects per connection, so a second connection with a different implementation re-pointed the codec for every connection already running.

It surfaced the way this class of bug does — as a wrong number rather than an error. The observer passed an uninstrumented codec, and the measurement on the other socket reported 10000 row(s) cost 0 json.decode call(s).

Guarded in connection.new, not protocol.init. Instrumenting the codec on purpose is a considered act through a documented door and test_protocol.lua does exactly that; two connections disagreeing by accident is the bug. The guard is mutation-proven: relaxing the condition turns the new test red.

Verification

12 passed, 0 failed, stylua clean
conformance v1 PASS (with phase 8) and v2 PASS, both including the persisted-identity restart
HTML5 PASS, v2 in headless Chromium
Wiki updated in the same shape: the four-observer table stays as provenance, with row two marked as the one now held by a test

Closes the last actionable item on #77. ## The gap `smoke.script` said so itself, in the header: *"Proving light mode is honoured for OTHER clients' transactions still needs a second connection and is not attempted here."* Phase 1 only ever checked the caller's own transaction. The cross-client behaviour was established by a hand-run four-observer measurement and written into the wiki as fact, with nothing re-checking it. ## Phase 8 v1 only — v2 has no light mode to produce a light frame. An **ordinary** observer, no light flag anywhere, watches a commit caused by the main socket. One commit, two sockets, asserted to differ: ``` SMOKE: PHASE8 OK same commit, two shapes: observer got TransactionUpdateLight (foreign request_id=14), caller got a full TransactionUpdate for reducer "send_message" ``` Both halves against the same transaction, because either alone is consistent with a server that ignores `light` entirely. Failable by construction — with the observer making the call instead: ``` SMOKE: FAIL the observer received a FULL update for another socket's commit ``` The observer is closed before phase 6, which times a frame budget and would otherwise pay for a second socket decoding its own copy of every insert. ## The defect it found `stdb.protocol` is pure and holds its JSON codec in a **module local**. `connection.new` injects per connection, so a second connection with a different implementation re-pointed the codec for every connection **already running**. It surfaced the way this class of bug does — as a wrong number rather than an error. The observer passed an uninstrumented codec, and the measurement on the *other* socket reported `10000 row(s) cost 0 json.decode call(s)`. Guarded in `connection.new`, not `protocol.init`. Instrumenting the codec on purpose is a considered act through a documented door and `test_protocol.lua` does exactly that; two *connections* disagreeing by accident is the bug. The guard is mutation-proven: relaxing the condition turns the new test red. ## Verification - `12 passed, 0 failed`, stylua clean - conformance **v1 PASS** (with phase 8) and **v2 PASS**, both including the persisted-identity restart - **HTML5 PASS**, v2 in headless Chromium - Wiki updated in the same shape: the four-observer table stays as provenance, with row two marked as the one now held by a test

yuris added 1 commit

2026-08-22 02:58:38 +00:00

test: prove the light-mode claim on two sockets, and stop a codec swap in silence

ci / ci (pull_request) Successful in 21s

Details

conformance / conformance (v1) (pull_request) Successful in 2m19s

Details

conformance / conformance (v2) (pull_request) Successful in 2m37s

Details

ac80ca89ac

The cross-client half of light mode was measured by hand and written into the
wiki, never tested: phase 1 only ever checked that the CALLER's own transaction
stays full. Phase 8 opens a second, ordinary socket - no light flag anywhere -
has the main socket call a reducer, and asserts the asymmetry on one commit: the
observer gets TransactionUpdateLight, the caller gets a full TransactionUpdate.
Either half alone is consistent with a server that ignores the flag, which is
why both are checked against the same transaction. Failable by construction:
have the observer make the call and it reports a full update.

Writing it found a real defect. stdb.protocol is pure and keeps its JSON codec
in a module local, and connection.new injects per connection, so a second
connection with a different implementation re-pointed the first one's decoding
with nothing to notice it by. It surfaced as the observer's uninstrumented codec
silencing the measurement running on the other socket - a wrong number, not an
error. Two connections in one process are supported, so this was reachable.

Guarded in connection.new rather than protocol.init, which stays permissive:
swapping the codec deliberately to wrap or instrument it is a considered act
through a documented door, and test_protocol.lua does exactly that. Two
connections disagreeing by accident is the bug, and connection.new is where it
can be seen.

Both quickstarts now place the send identically, so neither placement reads as
load-bearing when only the socket is.

yuris merged commit cdf230b0aa into main

2026-08-22 03:04:16 +00:00

yuris referenced this pull request from a commit

2026-08-22 03:04:17 +00:00

test: prove the light-mode claim on two sockets, and stop a codec swap in silence (#104)

yuris referenced this pull request

2026-08-22 03:07:15 +00:00

Developer experience and documentation #77