Isolate Node and Bun latency workloads
The combined Node/Bun grpc-provider-conformance --latency run reused latency/before and latency/after in one service. Node filled them; Bun ignored its failed seed append, replayed Node's records and failed on its next conditional append. The child's stderr reproduced this deterministic tail conflict.
Use latency/<runtime>/<case> and require the seed append to succeed before opening a follower. Parameterize only the benchmark's work count so shrinking verification can execute the real workload quickly. Runtime defaults, warm-up count, sample count and percentile calculation remain the normal benchmark values.
Decisions
- This is a qualification-fixture fix. The SDK's Streams protocol, transports, application files and services are unchanged.
- The property runs both runtime labels over the same real MemoryStreamProvider, in either order, with exact accepted-record counts and independent final cursors. The negative control aliases both labels to one namespace and must fail the same verifier after the explicit seed rejection. It does not rely on a timeout or latency threshold.
- TLS identity generation uses an ephemeral OpenSSL fixture for this run because the cached certificate executable was absent. No implicit cargo build is launched by the benchmark wrapper.
Validation
- One bb1 batch: TS declarations/typecheck passed (0.039 s); both shrinking property/negative-control tests passed (0.164 s); the full Node and Bun latency qualification passed (1.116 s). Log:
/home/var/log/buildbox/2026-10-16T151210087Z-43858.log. - Each runtime uses 16 warm-up appends and 128 measured appends. Measurement starts before append submission and stops at follower yield; awaiting the append acknowledgement occurs afterward. Every sequence and accepted append is checked. There are no wall-clock success assertions.
- Windows
lb.ps1 cargo check --locked --manifest-path typescript/packages/stream/models/Cargo.toml --testspassed (0.38 s plus 15 s slot wait). This standalone model crate has test targets and no library target.
Loopback results in milliseconds (p50 / p99):
| Runtime | Memory | Legacy gRPC Follow | Multiplexed Streams session |
|---|---|---|---|
| Node | 0.045318 / 0.179080 | 0.967521 / 1.842713 | 0.967421 / 1.985289 |
| Bun | 0.045408 / 0.109024 | 0.666477 / 2.822854 | 0.760108 / 3.400266 |
The service is the local TLS gRPC conformance service backed by WASM MemoryStream. These shared-host diagnostics do not establish a speedup: session p99 was higher in this single-follow workload. Connection scaling is qualified separately by #644's work counters and 10k workload.
Live steps
Deployed-service p50/p99 remains pending an endpoint and credential. The Cloud session transport at inspected revision f019b4a25e36151dd7d4a59c3b259b9b8fd80aea still restricts subscriptions to ALL follows; full tiered qualification also requires LATEST, live children and checked cursor confirmation there.
Greptile P2 fix
Both the model driver and benchmark now import measure from session-latency-measure.mjs. Its only import is node:assert/strict; benchmark clients, generated transport setup and dist modules stay in session-latency.mjs.
Reused the built Cargo latency test executable with typescript/packages/stream/dist temporarily removed. Asserted the directory was absent before and after: 2 tests passed in 0.368 s, including the namespace-collision negative control. The model generated no dist output. Restored the directory and ran the full Node/Bun TLS latency benchmark: passed in 1.970 s. No Cargo rebuild was needed for this JS-only extraction. Log: /home/var/log/buildbox/2026-10-16T153924368Z-117108.log.
Windows model-crate compile proof also passed: 0.24 s, excluding 450 s slot wait (lb.ps1 cargo check --locked --manifest-path typescript/packages/stream/models/Cargo.toml --tests).