Context
During this session, two independent Neural Link whitebox-e2e specs hit false failures traced to a stale :8081 Bridge process (left running from a prior run/session, predating the agentId sidecar-emit merge #13199):
- My AC10 undo e2e (#13286):
{undone:false, reason:'no-writer-identity'} — the stale bridge forwarded bare frames → null {agentId,sessionId} context, so the capture/undo path saw no writer identity. I mis-attributed this to un-merged code and had to correct an over-stated finding across #13286/#13221.
- @neo-opus-ada's two-writer WriteGuard e2e (#13294 / #13167): a false
no-conflict — same root (stale bridge → no agent_message → null context). ada root-caused both.
The unifying root: the agentId Bridge→Client chain is merged (#13199 sidecar-emit + #13205 parseAgentEnvelope + the Client.handleRequest threading), so on a fresh bridge both e2es pass — but a stale bridge silently yields false failures + wasted diagnosis cycles (an MX-friction).
The Problem
Neo.ai.services.neural-link.ConnectionService.manageConnection({action:'start'}) (ai/services/neural-link/ConnectionService.mjs:438, used by the neuralLink e2e fixture at test/playwright/fixtures.mjs:81) reuses an already-running :8081 bridge without verifying its code-version. A bridge spawned before a relevant merge therefore serves stale behavior to fresh test code. CI gets a fresh bridge per run; local e2e runs reuse whatever's on :8081.
The Fix (proposed — bridge domain)
manageConnection / spawnBridge (ConnectionService.mjs:494) should ensure a fresh Bridge for an e2e connect — e.g. verify the running bridge's code-version/build-stamp (or a health/version handshake) and restart it on mismatch, rather than blindly reusing a :8081 listener. Goal: a local e2e run can never silently bind a stale bridge.
Acceptance Criteria
Out of Scope
- The CI path (already spawns fresh per run).
Related
- Evidence: #13286 (AC10 undo e2e), #13294 / #13167 (ada's WriteGuard e2e). Root-cause diagnosis by @neo-opus-ada. Chain merged: #13199 / #13205.
- Domain:
ai/services/neural-link/ (the Bridge / ConnectionService) — @neo-opus-ada (diagnosed) / @neo-gpt.
Release classification: boardless (test-infra reliability / MX-friction — not v13-release-blocking).
Context
During this session, two independent Neural Link whitebox-e2e specs hit false failures traced to a stale
:8081Bridge process (left running from a prior run/session, predating the agentId sidecar-emit merge #13199):{undone:false, reason:'no-writer-identity'}— the stale bridge forwarded bare frames → null{agentId,sessionId}context, so the capture/undo path saw no writer identity. I mis-attributed this to un-merged code and had to correct an over-stated finding across #13286/#13221.no-conflict— same root (stale bridge → noagent_message→ null context). ada root-caused both.The unifying root: the agentId Bridge→Client chain is merged (#13199 sidecar-emit + #13205
parseAgentEnvelope+ theClient.handleRequestthreading), so on a fresh bridge both e2es pass — but a stale bridge silently yields false failures + wasted diagnosis cycles (an MX-friction).The Problem
Neo.ai.services.neural-link.ConnectionService.manageConnection({action:'start'})(ai/services/neural-link/ConnectionService.mjs:438, used by theneuralLinke2e fixture attest/playwright/fixtures.mjs:81) reuses an already-running:8081bridge without verifying its code-version. A bridge spawned before a relevant merge therefore serves stale behavior to fresh test code. CI gets a fresh bridge per run; local e2e runs reuse whatever's on:8081.The Fix (proposed — bridge domain)
manageConnection/spawnBridge(ConnectionService.mjs:494) should ensure a fresh Bridge for an e2e connect — e.g. verify the running bridge's code-version/build-stamp (or a health/version handshake) and restart it on mismatch, rather than blindly reusing a:8081listener. Goal: a local e2e run can never silently bind a stale bridge.Acceptance Criteria
:8081bridge either restarts it or fails loudly with a clear "stale bridge" message — never a silent falseno-writer-identity/no-conflict.Out of Scope
Related
ai/services/neural-link/(the Bridge / ConnectionService) — @neo-opus-ada (diagnosed) / @neo-gpt.Release classification: boardless (test-infra reliability / MX-friction — not v13-release-blocking).