mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-12 02:02:13 +03:00
12228626c1
Follow-up to the earlier truncated-request-body transcript fix, found by re-checking the live dashboard: a specific /v1/responses request still showed nothing for its own turn even though its body genuinely was truncated by logTruncation.ts's truncateForLog(). Root cause (two parts): 1. truncateForLog() only counted messages[] (Chat Completions) and contents[] (Gemini) — never input[] (Responses API) — so a truncated Responses API request's summary carried NO count field at all. 2. buildMultiRowConversation()'s earlier fix defaulted an unknown count to 0, which silently produced "0 new turns" instead of surfacing that the count was simply unavailable — same end symptom as the original bug (nothing shown) despite the row being genuinely truncated. Fixes: - logTruncation.ts now also sets messageCount for input[] bodies (root fix, only helps requests logged from here forward). - multiRowConversation.ts now distinguishes "known count" (existing specific "N messages not shown" placeholder + correct bookkeeping) from "unknown count" (a generic placeholder, since we can't safely diff against previousTotal without a real number) — needed for the already-persisted historical data on omniroute-dev that will never retroactively get a messageCount. Test plan: - New TDD tests for both gaps (Responses API count capture in logTruncation, unknown-count placeholder in multiRowConversation), confirmed failing before each fix and passing after - npm run typecheck:core / npm run lint / npm run check:file-size — clean - npm run test:unit — 27223 tests, same 4 pre-existing/unrelated failures as the last confirmed-clean run (no new regressions) - npm run test:vitest — 291/291 passed - Rebuilt and redeployed to omniroute-dev