fix(combo): time a rotated attempt from its own send, not the combo target's start - #8749

Summary

The problem. When a combo target rotates to another key or OAuth account before it gives up (for example a multi-account Antigravity target answering 429 on each account), the request log recorded the last account's attempt as if it had started when the combo target started. That attempt's durationMs (and firstOutputMs, when it succeeded) silently included every earlier account's time, so a request's attempts summed to more time than the request itself took.

What changes. The combo now times the live attempt from the moment the rotation sealed the previous one (childLog.activeAttemptStartedAt, which noteProviderAttemptSend already moves forward), falling back to the target's start when nothing rotated. The native combo lane gets the same correction in its finish.

Impact for users. Request logs, the usage ledger, and any dashboard that splits a request into "earlier attempts / waiting for upstream / streaming" stop double-counting failed accounts. Example from a real log row before the fix: three Antigravity accounts recorded 268 + 370 + 1017 ms (the third really took about 380 ms) before the request failed over to Anthropic, inside a request that lasted 1962 ms in total. Routing and delivery are unchanged.

What this is not. I investigated a report that combo failover buffers the whole upstream stream before relaying it. It does not: preflightComboStreamResponse holds bytes only until the first output event or a terminal, then relays live. The new test pins that down, so a future change that turns the relay into a burst fails the suite.

Technical details:

• src/server/responses/core-combo.ts: a segmentStartedAt() helper replaces the fixed started in every finishRequestAttempt/firstOutputMs computation and in the activeAttemptStartedAt handed to the parent log at commit. The [combo] ... failed after Nms console line still reports the whole target's time, on purpose.
• src/server/responses/core-combo-native.ts: the attempt handle's finish uses the same segment start.
• tests/responses/combo-stream-attempt-timing.test.ts (new, registered in layout-combos.json and the expected-layout fixture):
  • a [429 target, paced streaming target] combo delivers five deltas spread over their real 120 ms gaps;
  • a target that rotates keys once through the real noteProviderAttemptSend seam records two attempts, each about one key's latency, and all attempts sum to no more than the elapsed time. Without the fix this case fails (Expected: < 260, Received: 372).

Verification

• bun run typecheck: passes.
• bun run structure:check: passes.
• bun test tests/responses/combo-stream-attempt-timing.test.ts: 2 pass; the rotation case fails on upstream/dev without the source change.
• Focused files, each run alone: tests/test-layout.test.ts (2 pass), tests/ci-workflows/file-size-ratchet.test.ts (9 pass), tests/responses/responses-combo-fallback-off.test.ts (12 pass), tests/responses/chat-native-combo.test.ts (27 pass), tests/responses/responses-combo-bridge-usage.test.ts (5 pass), tests/responses/combo-codex-ws-overload-failover.test.ts (2 pass), tests/responses/responses-account-label.test.ts (10 pass with --timeout 60000; four cases hit the default 5 s timeout under CPU contention).
• tests/server/server-combo-failover-e2e.test.ts did not finish within 500 s on this machine both with and without this change, so it is left to CI.
• I did not run the full suite locally: several worktrees were running suites on the same machine, and a combined focused run hit a 10-minute timeout from CPU contention. The full suite is left to CI.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed. (No user-facing docs describe attempt timing.)
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults. (Logging arithmetic only; no new fields, no credential handling.)

Review readiness checklist

This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:

• Required local validation passed; commands, results, and any full-suite exception are documented.

• I pushed my PR to a recent dev commit (at most 10 behind; a maintainer may still ask for the exact tip before merge).

• I resolved all correct Codex and CodeRabbit findings.

• My PR is ready for review.