fix(conversations): bound reconnect walk + memoize turn hashes — 10-130s pre-routing stall on long agent histories

[adevwithpurpose]

Summary

resolveConversationId (the agentic conversation tracker, open-sse/services/conversationTracker.ts) blocks the chat request path for 10–130 s on long coding-agent histories. On a production deployment routing a real 1500-message / 92-tool agent session, measured POST → ROUTING latency was:

Request class (same instance, same window)	n	p50	max	>10 s
≥ 200 messages	132	12.6 s	130.2 s	128
< 200 messages	70	0.2 s	0.6 s	0

The stall grows as the conversation grows (early turns 0.2 s → late turns 130 s), and its synchronous work also starves unrelated endpoints — a trivial GET /healthz on the same instance spiked to 11.1 s during large-request processing. This is the request-path face of the long-context cost family tracked in #7847.

Root cause

resolveConversationId runs once per chat request in the validate phase, before routing (src/sse/handlers/chat.ts, resolveConversationId call). To detect continuation it must find where the incoming turn list reconnects to a recorded chain. findReconnectMatch:

• iterates every start turn × every duplicate anchor sharing that turn's content hash (real agentic traffic is full of byte-identical tool outputs — the module's own docs note 28 duplicates of a single turn in one real conversation), and
• walks the chain forward, computing chainNodeId per step — two createHmac("sha256") calls per step, with the turn's full (often multi-KB) text re-hashed at every step (no memoization).

That is O(starts × anchors × walkLength) full-content HMACs, synchronous on the request path. A local repro of the exact duplicate-heavy shape (800 turns, alternating identical "ok" tool outputs and 40 KB file-content turns, second request editing every large turn) spent 17.2 s inside resolveConversationId on otherwise-idle hardware.

Fix (two surgical changes in conversationTracker.ts)

1. Memoize turn content hashes per request. Each turn is hashed exactly once (turnHashes); every walk step then hashes ~130 fixed-size bytes (parentId + turnHash) instead of re-hashing the turn's full text twice. buildNewNodes reuses the same memoized hashes.
2. Bound the walk with a shared step budget (DEFAULT_RECONNECT_MAX_STEPS = 150_000), charged one step per anchor claim and per forward step, shared across all fingerprint candidates. Budget exhaustion degrades exactly like a no-match — the request mints a new conversation — never an unverified attachment and never unbounded latency.

findReconnectMatch is now exported with { turnHashes, maxSteps, budget } options so both properties are directly unit-testable.

Result on the repro above: 17.2 s → 0.3 s (suite runs in ~1.2 s including DB setup). Selection semantics are unchanged: longest verified run still wins, ties still break toward the childless anchor, edits still mint a new conversation, compaction-window reconnection still works.

Tests

tests/unit/conversationTracker-reconnect-7847.test.ts (new):

• budget cap: adversarial duplicate-anchor shape with maxSteps: 50 reports stepsUsed ≤ 50;
• zero-budget degradation: a genuine 3-turn continuation matches with the default budget, and yields no match (not an unverified attach) with maxSteps: 0;
• wall-clock regression guard: the duplicate-heavy 800-turn end-to-end resolve must complete under 2 s (fails at 17.2 s pre-fix);
• DB-backed tests use an isolated temp DATA_DIR and close the DB handle in test.after.

All 17 existing conversationTracker.test.ts semantics tests pass unchanged, plus conversationTurnContent.test.ts (5). npm run typecheck:core clean; scoped eslint + prettier clean; full husky pre-commit gates passed.

Notes

• ⚠️ base-red inherited: 🔴 Release branch not green: release/v3.8.50 #9985
• No public API or schema changes; no new env vars (the budget constant is code-level and exported for tests).
• Related: feat(backend): full request-body clones amplify long-context peak memory #7847 (long-context full-body amplification — this fixes the request-path stall component), fix(backend): long-context compression can exhaust V8 heap and terminate OmniRoute #7849 (session-dedup quadratic memory, already fixed).