feat(inputlayer-js): routed connection core with request ids, deadlines and reconnect - #237

base p50=0.520/0.476ms p99=0.734/0.605ms; head p50=0.499/0.477ms p99=0.633/0.597ms

 RUN  v3.2.7 ~/.no-mistakes/worktrees/9eea230c3aae/01M43BFB8M18GTF3V2STQB1V68/packages/inputlayer-js

stdout | tests/zz_nm_latency.test.ts > latency base vs head
[latency] base(1ee8c8f8): sequential ?e(1,Y) x3000 p50=0.520ms p90=0.630ms p99=0.734ms

stdout | tests/zz_nm_latency.test.ts > latency base vs head
[latency] head(e9621371): sequential ?e(1,Y) x3000 p50=0.499ms p90=0.542ms p99=0.633ms

stdout | tests/zz_nm_latency.test.ts > latency base vs head
[latency] base(1ee8c8f8): sequential ?e(1,Y) x3000 p50=0.476ms p90=0.514ms p99=0.605ms

stdout | tests/zz_nm_latency.test.ts > latency base vs head
[latency] head(e9621371): sequential ?e(1,Y) x3000 p50=0.477ms p90=0.508ms p99=0.597ms

 ✓ tests/zz_nm_latency.test.ts (1 test) 6796ms
   ✓ latency base vs head  6795ms

 Test Files  1 passed (1)
      Tests  1 passed (1)
   Start at  12:27:04
   Duration  7.39s (transform 266ms, setup 0ms, collect 331ms, tests 6.80s, environment 0ms, prepare 74ms)

🔧 Fix applied.
6 issues (5 warnings, 1 info) still open:

• ⚠️ packages/inputlayer-js/src/connection.ts:599 - probeServer() assumes that "a live server answers at once, even while computing". That is false when the engine's request pipeline is full. The engine reads client frames, including WebSocket pings, only while requests.has_capacity() (ws.rs:443, pipeline.rs:99), and an admitted cancel takes a pipeline slot until its cancel_ack is released (ws.rs:606-616). With the default bounds (client maxInFlight 15, server 16), 15 calls in flight plus one deadline cancel fill all 16 slots, so the probe's ping is not read and gets no pong. After timeoutGraceMs/2 (1 s) the client terminates a healthy connection. Example: Promise.all of a write that is slow to commit plus 14 queries pipelined behind it (replies come back in request order). At the write's deadline the client sends cancel (too_late) and the probe. The ping goes unread, and after 1 s every call fails with ConnectionLostError: the write with mayHaveCommitted, all the queries needlessly. The connection then reconnects and emits session_reset, so session state is lost. This probe code is from the original commit, and round 1 (the F2 fix) kept it. Fix: don't terminate on a missing pong while the server's window may be full (inFlight.size plus outstanding cancels >= maxInFlight), or count any frame received since the probe started as proof the server is alive. The overdue timer already bounds the call.
• ⚠️ packages/inputlayer-js/src/connection.ts:556 - overdue() fails the call at deadline + grace even when its reply has already started arriving (call.stream is set by result_start). Example: a query with timeoutMs: 30000 finishes computing at 29 s and starts streaming a large result over a slow link. At 32 s the call rejects with DeadlineExceededError, which claims no reply came, and the rest of a successful result is thrown away. Each later result_chunk and the result_end is then counted separately in staleReplies, because the id is in neither inFlight nor abandoned. The operator's F2 decision limits local failure to a call where "neither the call's reply nor its cancel_ack has arrived", and this path came in with the round-1 F2 fix. Fix: in overdue, if call.stream is set, keep waiting for result_end (or re-arm the grace timer). When a call is failed locally, add its id to abandoned so its remaining frames are dropped as one stale reply.
• ⚠️ packages/inputlayer-js/src/connection.ts:731 - finish() removes a call from inFlight as soon as the client fails it locally, and then pump() sends more requests, but the engine still holds the request until it replies. Replies come back in request order, so this is reachable: queries pipelined behind a slow write go overdue together and free their slots at once. The client then sends another full window, and the engine's unreleased count goes past ws_max_in_flight_requests. The engine then stops reading, so a later cancel (from an AbortSignal) or probe ping is not read until the head of the line finishes. That breaks the intent's invariant: "at most ws_max_in_flight_requests - 1 requests in flight ... so a cancel can always be sent". The round-1 F2 fix introduced this through overdue() (line 561); abandon() (line 742) has the same early release for broken streams. Fix: keep a locally failed id counted against maxInFlight (for example in abandoned, checked by pump) until its final frame (result, error or result_end) arrives or the connection closes.
• ℹ️ packages/inputlayer-js/src/connection.ts:976 - After an AuthenticationError the reconnect loop stops at once (line 955), yet the give-up error always says Reconnecting failed after ${maxReconnectAttempts} attempt(s). Example: a credential revoked during an outage gives "failed after 10 attempt(s)" after one attempt. Fix: report the actual attempt count.
• ⚠️ packages/inputlayer-js/src/connection.ts:577 - Introduced by the round-4 N1/N3 fixes, which followed the operator's instructions to the letter but together leave no way to get a connection back. A locally failed call's slot now stays in abandoned until its final frame arrives or the socket closes (line 577; and line 770 for broken streams). pump counts those slots (line 534). The probe no longer terminates while inFlight + abandoned + control >= maxInFlight (line 625). The keepalive ping's failure is ignored (lines 1026-1029: 'A failed ping surfaces as a close', which never happens on a half-open socket).

Two paths leave the connection open but unable to send.
(a) The F2 case the operator required to stay usable: a live server that answers pings but never replies to a request (a lost reply). Each such call holds a slot for good. After maxInFlight (15) of them, pump never sends again. Every later call fails with DeadlineExceededError 'nothing was applied', or hangs forever with timeoutMs: 0. Pongs keep the socket alive, so it never reconnects. The silent_server tests only cover one slot.
(b) A half-open connection (host crash or partition) while 15 calls are in flight: at each deadline, outstanding >= maxInFlight, so the probe never terminates. All 15 go to abandoned, and the same wedge follows until the OS times out the TCP connection, which can take tens of minutes.

Fixing this means choosing a new liveness rule, which needs a decision. For example: drop and reconnect the connection when abandoned alone fills the window, or when an abandoned slot outlives a bound. Or treat a keepalive ping that times out as a dead connection. Without one of these, the N3 slot accounting turns a single lost reply per slot into a permanently dead handle.

• ⚠️ packages/inputlayer-js/src/connection.ts:574 - Introduced by the round-4 N2 fix. When the grace period ends while a reply is streaming, overdue returns with call.deadline cleared and does not re-arm any timer, so the call has no bound left. If the connection goes half-open mid-stream, nothing ever notices:
• the chunks that already arrived cleared the probe (onFrame calls clearProbe);
• the keepalive skips whenever inFlight.size > 0 (line 1026), so the client sends nothing and TCP never detects the dead peer.
  Example: a query with timeoutMs: 30000 starts streaming at 29 s, and the network partitions at 31 s. The call stays pending forever and holds its slot. Before round 4 it failed at deadline + grace. Fix, using the alternative the operator's N2 instruction allows ('or re-arm the grace timer'): in overdue, if call.stream is set, re-arm call.deadline = setTimeout(() => this.overdue(call), timeoutGraceMs) and reset it on each result_chunk. A stream that keeps arriving completes; a stalled one fails locally like a silent call.

🔧 Fix applied.
8 issues (1 error, 5 warnings, 2 infos) still open:

• ⚠️ packages/inputlayer-js/src/connection.ts:599 - probeServer() assumes that "a live server answers at once, even while computing". That is false when the engine's request pipeline is full. The engine reads client frames, including WebSocket pings, only while requests.has_capacity() (ws.rs:443, pipeline.rs:99), and an admitted cancel takes a pipeline slot until its cancel_ack is released (ws.rs:606-616). With the default bounds (client maxInFlight 15, server 16), 15 calls in flight plus one deadline cancel fill all 16 slots, so the probe's ping is not read and gets no pong. After timeoutGraceMs/2 (1 s) the client terminates a healthy connection. Example: Promise.all of a write that is slow to commit plus 14 queries pipelined behind it (replies come back in request order). At the write's deadline the client sends cancel (too_late) and the probe. The ping goes unread, and after 1 s every call fails with ConnectionLostError: the write with mayHaveCommitted, all the queries needlessly. The connection then reconnects and emits session_reset, so session state is lost. This probe code is from the original commit, and round 1 (the F2 fix) kept it. Fix: don't terminate on a missing pong while the server's window may be full (inFlight.size plus outstanding cancels >= maxInFlight), or count any frame received since the probe started as proof the server is alive. The overdue timer already bounds the call.
• ⚠️ packages/inputlayer-js/src/connection.ts:556 - overdue() fails the call at deadline + grace even when its reply has already started arriving (call.stream is set by result_start). Example: a query with timeoutMs: 30000 finishes computing at 29 s and starts streaming a large result over a slow link. At 32 s the call rejects with DeadlineExceededError, which claims no reply came, and the rest of a successful result is thrown away. Each later result_chunk and the result_end is then counted separately in staleReplies, because the id is in neither inFlight nor abandoned. The operator's F2 decision limits local failure to a call where "neither the call's reply nor its cancel_ack has arrived", and this path came in with the round-1 F2 fix. Fix: in overdue, if call.stream is set, keep waiting for result_end (or re-arm the grace timer). When a call is failed locally, add its id to abandoned so its remaining frames are dropped as one stale reply.
• ⚠️ packages/inputlayer-js/src/connection.ts:731 - finish() removes a call from inFlight as soon as the client fails it locally, and then pump() sends more requests, but the engine still holds the request until it replies. Replies come back in request order, so this is reachable: queries pipelined behind a slow write go overdue together and free their slots at once. The client then sends another full window, and the engine's unreleased count goes past ws_max_in_flight_requests. The engine then stops reading, so a later cancel (from an AbortSignal) or probe ping is not read until the head of the line finishes. That breaks the intent's invariant: "at most ws_max_in_flight_requests - 1 requests in flight ... so a cancel can always be sent". The round-1 F2 fix introduced this through overdue() (line 561); abandon() (line 742) has the same early release for broken streams. Fix: keep a locally failed id counted against maxInFlight (for example in abandoned, checked by pump) until its final frame (result, error or result_end) arrives or the connection closes.
• ℹ️ packages/inputlayer-js/src/connection.ts:976 - After an AuthenticationError the reconnect loop stops at once (line 955), yet the give-up error always says Reconnecting failed after ${maxReconnectAttempts} attempt(s). Example: a credential revoked during an outage gives "failed after 10 attempt(s)" after one attempt. Fix: report the actual attempt count.
• ⚠️ packages/inputlayer-js/src/connection.ts:577 - Introduced by the round-4 N1/N3 fixes, which followed the operator's instructions to the letter but together leave no way to get a connection back. A locally failed call's slot now stays in abandoned until its final frame arrives or the socket closes (line 577; and line 770 for broken streams). pump counts those slots (line 534). The probe no longer terminates while inFlight + abandoned + control >= maxInFlight (line 625). The keepalive ping's failure is ignored (lines 1026-1029: 'A failed ping surfaces as a close', which never happens on a half-open socket).

Two paths leave the connection open but unable to send.
(a) The F2 case the operator required to stay usable: a live server that answers pings but never replies to a request (a lost reply). Each such call holds a slot for good. After maxInFlight (15) of them, pump never sends again. Every later call fails with DeadlineExceededError 'nothing was applied', or hangs forever with timeoutMs: 0. Pongs keep the socket alive, so it never reconnects. The silent_server tests only cover one slot.
(b) A half-open connection (host crash or partition) while 15 calls are in flight: at each deadline, outstanding >= maxInFlight, so the probe never terminates. All 15 go to abandoned, and the same wedge follows until the OS times out the TCP connection, which can take tens of minutes.

Fixing this means choosing a new liveness rule, which needs a decision. For example: drop and reconnect the connection when abandoned alone fills the window, or when an abandoned slot outlives a bound. Or treat a keepalive ping that times out as a dead connection. Without one of these, the N3 slot accounting turns a single lost reply per slot into a permanently dead handle.

• ⚠️ packages/inputlayer-js/src/connection.ts:574 - Introduced by the round-4 N2 fix. When the grace period ends while a reply is streaming, overdue returns with call.deadline cleared and does not re-arm any timer, so the call has no bound left. If the connection goes half-open mid-stream, nothing ever notices:
• the chunks that already arrived cleared the probe (onFrame calls clearProbe);
• the keepalive skips whenever inFlight.size > 0 (line 1026), so the client sends nothing and TCP never detects the dead peer.
  Example: a query with timeoutMs: 30000 starts streaming at 29 s, and the network partitions at 31 s. The call stays pending forever and holds its slot. Before round 4 it failed at deadline + grace. Fix, using the alternative the operator's N2 instruction allows ('or re-arm the grace timer'): in overdue, if call.stream is set, re-arm call.deadline = setTimeout(() => this.overdue(call), timeoutGraceMs) and reset it on each result_chunk. A stream that keeps arriving completes; a stalled one fails locally like a silent call.
• 🚨 packages/inputlayer-js/src/connection.ts:1043 - The round-5 L1 fix brought this in. The keepalive now sends an application {type:'ping', id} while calls are in flight and drops the socket when no pong arrives within timeoutGraceMs. The engine, however, answers an application ping as an ordinary pipelined request (request.rs:100 Request::immediate, "released in order with the others"; ws.rs:137 "Replies come back in request order"). Its pong therefore waits behind every earlier request. Concrete sequence with the defaults (keepaliveMs 20 000, grace 2 000, defaultTimeoutMs 30 000): kg.execute(q) starts a query that takes 25 s on a healthy server. Nothing else is sent, so the keepalive tick at about 20 s sends a ping, and that pong cannot be released until the query's reply at 25 s. At about 22 s request() times out and ws.terminate() runs. The healthy query fails with ConnectionLostError, a write fails with mayHaveCommitted, and the reconnect emits session_reset. With timeoutMs: 0 (no deadline), any call that runs longer than keepaliveMs + grace is killed the same way. The same false positive occurs with inFlight 0 when the engine still holds an abandoned call: the round-5 change no longer counts abandoned calls, but the engine still orders their replies first. Sibling: the ping also takes an engine pipeline slot, so 15 calls in flight plus the keepalive ping fill the engine's 16 slots. The engine then stops reading, and a deadline or signal cancel can no longer be read, which breaks the intent's 'ws_max_in_flight_requests - 1 so a cancel can always be sent'. The tests cannot catch this because the mock server (connection.test.ts:87) answers application pings at once, out of order. Fix: check liveness with a transport ws.ping() and its pong (as probeServer does; that pong does not wait behind the request order and takes no pipeline slot). Keep the application ping only for idle keep-alive, with no terminate-on-timeout, or count any frame received as proof of life. Add a mock fixture in which a ping's pong waits behind a slow reply.
• ℹ️ packages/inputlayer-js/src/client.ts:55 - The keepaliveMs docs in client.ts:55 and docs/content/docs/guides/js-sdk.mdx:66 still describe only idle keep-alive. They don't say that the round-5 keepalive now also drops and reconnects a connection whose ping goes unanswered within timeoutGraceMs, though connection.ts:88-93 was updated to say so. Align the wording.

🔧 Fix applied.
8 issues (1 error, 5 warnings, 2 infos) still open:

• ⚠️ packages/inputlayer-js/src/connection.ts:599 - probeServer() assumes that "a live server answers at once, even while computing". That is false when the engine's request pipeline is full. The engine reads client frames, including WebSocket pings, only while requests.has_capacity() (ws.rs:443, pipeline.rs:99), and an admitted cancel takes a pipeline slot until its cancel_ack is released (ws.rs:606-616). With the default bounds (client maxInFlight 15, server 16), 15 calls in flight plus one deadline cancel fill all 16 slots, so the probe's ping is not read and gets no pong. After timeoutGraceMs/2 (1 s) the client terminates a healthy connection. Example: Promise.all of a write that is slow to commit plus 14 queries pipelined behind it (replies come back in request order). At the write's deadline the client sends cancel (too_late) and the probe. The ping goes unread, and after 1 s every call fails with ConnectionLostError: the write with mayHaveCommitted, all the queries needlessly. The connection then reconnects and emits session_reset, so session state is lost. This probe code is from the original commit, and round 1 (the F2 fix) kept it. Fix: don't terminate on a missing pong while the server's window may be full (inFlight.size plus outstanding cancels >= maxInFlight), or count any frame received since the probe started as proof the server is alive. The overdue timer already bounds the call.
• ⚠️ packages/inputlayer-js/src/connection.ts:556 - overdue() fails the call at deadline + grace even when its reply has already started arriving (call.stream is set by result_start). Example: a query with timeoutMs: 30000 finishes computing at 29 s and starts streaming a large result over a slow link. At 32 s the call rejects with DeadlineExceededError, which claims no reply came, and the rest of a successful result is thrown away. Each later result_chunk and the result_end is then counted separately in staleReplies, because the id is in neither inFlight nor abandoned. The operator's F2 decision limits local failure to a call where "neither the call's reply nor its cancel_ack has arrived", and this path came in with the round-1 F2 fix. Fix: in overdue, if call.stream is set, keep waiting for result_end (or re-arm the grace timer). When a call is failed locally, add its id to abandoned so its remaining frames are dropped as one stale reply.
• ⚠️ packages/inputlayer-js/src/connection.ts:731 - finish() removes a call from inFlight as soon as the client fails it locally, and then pump() sends more requests, but the engine still holds the request until it replies. Replies come back in request order, so this is reachable: queries pipelined behind a slow write go overdue together and free their slots at once. The client then sends another full window, and the engine's unreleased count goes past ws_max_in_flight_requests. The engine then stops reading, so a later cancel (from an AbortSignal) or probe ping is not read until the head of the line finishes. That breaks the intent's invariant: "at most ws_max_in_flight_requests - 1 requests in flight ... so a cancel can always be sent". The round-1 F2 fix introduced this through overdue() (line 561); abandon() (line 742) has the same early release for broken streams. Fix: keep a locally failed id counted against maxInFlight (for example in abandoned, checked by pump) until its final frame (result, error or result_end) arrives or the connection closes.
• ℹ️ packages/inputlayer-js/src/connection.ts:976 - After an AuthenticationError the reconnect loop stops at once (line 955), yet the give-up error always says Reconnecting failed after ${maxReconnectAttempts} attempt(s). Example: a credential revoked during an outage gives "failed after 10 attempt(s)" after one attempt. Fix: report the actual attempt count.
• ⚠️ packages/inputlayer-js/src/connection.ts:577 - Introduced by the round-4 N1/N3 fixes, which followed the operator's instructions to the letter but together leave no way to get a connection back. A locally failed call's slot now stays in abandoned until its final frame arrives or the socket closes (line 577; and line 770 for broken streams). pump counts those slots (line 534). The probe no longer terminates while inFlight + abandoned + control >= maxInFlight (line 625). The keepalive ping's failure is ignored (lines 1026-1029: 'A failed ping surfaces as a close', which never happens on a half-open socket).

Two paths leave the connection open but unable to send.
(a) The F2 case the operator required to stay usable: a live server that answers pings but never replies to a request (a lost reply). Each such call holds a slot for good. After maxInFlight (15) of them, pump never sends again. Every later call fails with DeadlineExceededError 'nothing was applied', or hangs forever with timeoutMs: 0. Pongs keep the socket alive, so it never reconnects. The silent_server tests only cover one slot.
(b) A half-open connection (host crash or partition) while 15 calls are in flight: at each deadline, outstanding >= maxInFlight, so the probe never terminates. All 15 go to abandoned, and the same wedge follows until the OS times out the TCP connection, which can take tens of minutes.

Fixing this means choosing a new liveness rule, which needs a decision. For example: drop and reconnect the connection when abandoned alone fills the window, or when an abandoned slot outlives a bound. Or treat a keepalive ping that times out as a dead connection. Without one of these, the N3 slot accounting turns a single lost reply per slot into a permanently dead handle.

• ⚠️ packages/inputlayer-js/src/connection.ts:574 - Introduced by the round-4 N2 fix. When the grace period ends while a reply is streaming, overdue returns with call.deadline cleared and does not re-arm any timer, so the call has no bound left. If the connection goes half-open mid-stream, nothing ever notices:
• the chunks that already arrived cleared the probe (onFrame calls clearProbe);
• the keepalive skips whenever inFlight.size > 0 (line 1026), so the client sends nothing and TCP never detects the dead peer.
  Example: a query with timeoutMs: 30000 starts streaming at 29 s, and the network partitions at 31 s. The call stays pending forever and holds its slot. Before round 4 it failed at deadline + grace. Fix, using the alternative the operator's N2 instruction allows ('or re-arm the grace timer'): in overdue, if call.stream is set, re-arm call.deadline = setTimeout(() => this.overdue(call), timeoutGraceMs) and reset it on each result_chunk. A stream that keeps arriving completes; a stalled one fails locally like a silent call.
• 🚨 packages/inputlayer-js/src/connection.ts:1043 - The round-5 L1 fix brought this in. The keepalive now sends an application {type:'ping', id} while calls are in flight and drops the socket when no pong arrives within timeoutGraceMs. The engine, however, answers an application ping as an ordinary pipelined request (request.rs:100 Request::immediate, "released in order with the others"; ws.rs:137 "Replies come back in request order"). Its pong therefore waits behind every earlier request. Concrete sequence with the defaults (keepaliveMs 20 000, grace 2 000, defaultTimeoutMs 30 000): kg.execute(q) starts a query that takes 25 s on a healthy server. Nothing else is sent, so the keepalive tick at about 20 s sends a ping, and that pong cannot be released until the query's reply at 25 s. At about 22 s request() times out and ws.terminate() runs. The healthy query fails with ConnectionLostError, a write fails with mayHaveCommitted, and the reconnect emits session_reset. With timeoutMs: 0 (no deadline), any call that runs longer than keepaliveMs + grace is killed the same way. The same false positive occurs with inFlight 0 when the engine still holds an abandoned call: the round-5 change no longer counts abandoned calls, but the engine still orders their replies first. Sibling: the ping also takes an engine pipeline slot, so 15 calls in flight plus the keepalive ping fill the engine's 16 slots. The engine then stops reading, and a deadline or signal cancel can no longer be read, which breaks the intent's 'ws_max_in_flight_requests - 1 so a cancel can always be sent'. The tests cannot catch this because the mock server (connection.test.ts:87) answers application pings at once, out of order. Fix: check liveness with a transport ws.ping() and its pong (as probeServer does; that pong does not wait behind the request order and takes no pipeline slot). Keep the application ping only for idle keep-alive, with no terminate-on-timeout, or count any frame received as proof of life. Add a mock fixture in which a ping's pong waits behind a slow reply.
• ℹ️ packages/inputlayer-js/src/connection.ts:639 - The round-6 K1/K2 doc updates (client.ts:55, connection.ts:92-94 and the header at connection.ts:24-28) say the connection is dropped when there is "no WebSocket pong and no frame within timeoutGraceMs". probeServer actually terminates after Math.floor(timeoutGraceMs / 2) (line 639). It also never terminates while inFlight.size + control.size >= maxInFlight, which the option docs leave out. The probe now runs on every keepalive tick rather than only after a deadline, so this window decides when an idle listener counts as dead. With the defaults it gives up after 1 s, where the docs say 2 s. Fix: make the docs and the code agree. Either state the half-grace window, or use the full timeoutGraceMs as the operator's K1 wording describes ("no pong and no frame within timeoutGraceMs").

🔧 Fix applied.
1 info still open:

• ℹ️ gui/lib/docs-bundle.ts:1482 - The committed GUI docs bundle is out of date. js-sdk.mdx was edited in later rounds, including this round's keepaliveMs comment at js-sdk.mdx:66-67, but the bundled guides/js-sdk content still has the older text keepaliveMs: 20_000, // ping a silent connection so it is never idle-closed (default: 20 000). Builds regenerate the bundle (gui/package.json prebuild), so the shipped GUI is not affected. The committed file still disagrees with its source, though. Fix: rerun node gui/scripts/bundle-docs.mjs and commit the result.

🔧 Fix applied.
✅ Re-checked - no issues remain.

✅ No issues found.

• Live validation: ✅ go - 14 of 15 scenarios driven live against the product

• npx vitest run tests/connection.test.ts tests/notifications.test.ts tests/statement-errors.test.ts (mock-server frame fixtures, 83 passed)
• make js-test-live (builds the release server and runs docs-queries plus connection live tests against it: 32 passed)
• tests/connection.integration.test.ts repeated 10 times against a live server, checking the deadline/cancel race (R1) for flakiness: 10/10 passed
• Custom live driver zz-nm-live-driver.integration.test.ts, which spawns disposable servers: keepalive vs a 3 s idle timeout, server restart, SIGKILL mid-call, server gone for good, rate limit at 5 msg/s, R2 deadline during reconnect, 30 pipelined calls with one abort
• Live latency comparison of the base SDK (ea9d5d3c src) against the new SDK on the same server: 2000 sequential small queries x3 rounds

✅ No issues found.

• Live validation: ✅ go - 9 of 9 scenarios driven live against the product

• cargo build --release --bin inputlayer-server, then isolated engines on 127.0.0.1:8197 (defaults), :8198 (INPUTLAYER_HTTP__WS_IDLE_TIMEOUT_MS=3000) and :8199 (rate limit raised), each with its own temp data dir
• INPUTLAYER_TEST_SERVER=ws://127.0.0.1:8197/ws npx vitest run tests/connection.integration.test.ts (7 live connection-core tests)
• Throwaway live scenario script (S1-S7) run against the real engines, with a controllable TCP proxy to simulate half-open, blackholed-reply and refused connections
• Throwaway latency benchmark: base SDK (1ee8c8f8 src) vs head SDK, 3000 sequential queries x2 rounds against the real engine
• npx vitest run tests/connection.test.ts (adversarial frame fixtures replayed through the mock server, 54 tests)

✅ No issues found.

✅ No issues found.

✅ No issues found.

✅ No issues found.

✅ No issues found.

✅ No issues found.