lint-staged's prettier pass on the prior commit reformatted a pre-existing
multi-line ternary (title attribute) past the 100-char print width,
growing the file 1256->1260 lines with no functional change. CI's
check:file-size gate caught the drift (frozen cap can only shrink).
The 8KB cap on logged request/response bodies (open-sse/handlers/chatCore/
logTruncation.ts::truncateForLog()) was hardcoded — trivially exceeded by
any real multi-turn agentic conversation, meaning the dashboard's "Full
Conversation" panel could only ever show a placeholder instead of the
actual messages for nearly every logged row of any conversation with real
substance.
- Added CHAT_LOG_MAX_BODY_KB env var (src/lib/logEnv.ts::
getChatLogMaxBodyBytes()), default 1024 KB (1MB) — a 128x bump from the
old hardcoded 8KB — following the same configurable-limit pattern as the
sibling CHAT_LOG_TEXT_LIMIT/CHAT_LOG_ARRAY_TAIL_ITEMS/etc. vars.
- Documented in .env.example and docs/reference/ENVIRONMENT.md (both
required — tests/unit/issue-7793-env-doc-sync-repro.test.ts and
check-env-doc-sync.test.ts enforce this pairing).
Found and fixed a real bug while wiring this up: estimateSize.ts's
estimateSizeFast() had its own hardcoded 256KB early-exit optimization
("stop walking once bytes clearly exceeds the caller's threshold"), so it
could never report a size above ~256KB regardless of the object's true
size — meaning any caller threshold configured above 256KB (like the new
1MB default) was silently unreachable; every payload would look "under
threshold" and truncation would never fire, letting arbitrarily large
bodies through unbounded (the opposite of intended, and a real memory-
protection regression). Fixed by giving estimateSizeFast() a parameterized
earlyExitAt (default unchanged at 262144, so isSmallEnoughForSemanticCache's
existing behavior is untouched), with truncateForLog() now passing its own
configured getChatLogMaxBodyBytes() value through.
Also adds a "Conversation" field to the request detail panel's metadata
grid (last, after "Combo"), showing the request's conversation id
(sessionTag) for quick reference/copy.
Test plan:
- New TDD tests for both fixes (Responses API messageCount capture — from
the previous commit — and the estimateSizeFast earlyExitAt parameter),
confirmed failing before each fix and passing after
- Bumped the two truncateForLog test fixtures that were sized against the
old 8KB threshold so they still genuinely exceed the new ~1MB default
- npm run typecheck:core / npm run lint / npm run check:file-size — clean
- npm run test:unit — 27132 tests, same 4 pre-existing/unrelated failures
as the last confirmed-clean run (no new regressions) — including the two
env/doc-sync contract tests that initially caught the missing
CHAT_LOG_MAX_BODY_KB documentation, now fixed
- npm run test:vitest — 291/291 passed
- Rebuilt and redeployed to omniroute-dev
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
vulnCount 10->22 (osv-scanner, measured in PR #9439's own CI run). Not a
dependency change from this PR — `git diff upstream/release/v3.8.50 HEAD --
package.json package-lock.json` is empty, neither file was touched anywhere
in this branch. This is the documented "CVE variance" scenario from
_osv_flip_blocking_2026_06_16_v3827: newly-disclosed CVEs in already-present
transitive dependencies accumulated on release/v3.8.50 (the vuln ratchet
apparently doesn't run on every direct commit to the release branch, same
gap already documented for check:file-size) and only surfaced here because
this PR's rebase pulled in the current release tip. Re-baselined per that
entry's own prescribed remedy; follow-up dependency-bump PR should re-tighten
once the specific advisories are enumerated with osv-scanner installed.
CI failures on PR #9439:
1. Migration version collision: upstream/release/v3.8.50 landed
134_proxy_logs_egress_ip.sql (#9291) after this branch's original rebase,
colliding with this branch's own 134_agentic_conversations.sql. Renamed
to 135_agentic_conversations.sql (re-rebased onto the current tip first).
2. check:file-size: rebaselined the files this PR's own feature growth pushed
over their frozen/cap thresholds (RequestLoggerDetail.tsx, RequestTimeline.tsx,
RequestLoggerV2.tsx, chat.ts, chatCore.ts — see the new
_rebaseline_2026_08_04_9439 entry for the itemized justification) plus
open-sse/executors/base.ts, which was already over its own frozen baseline
on release/v3.8.50 independent of this branch (confirmed via `git diff
upstream/release/v3.8.50 HEAD -- open-sse/executors/base.ts` — empty).
3. A third real bug, found by re-checking the live dashboard after the
previous round's fixes: a request with a long real conversation chain
showed only its own response in the "Full Conversation" panel. Root
cause: open-sse/handlers/chatCore/logTruncation.ts's truncateForLog()
replaces any request body over ~8KB with a bare {_truncated,
_originalBytes, messageCount, ...} summary, dropping messages/input
entirely — the norm, not the exception, for any conversation with real
substance. buildRequestTurns() legitimately found nothing to parse, so
the transcript silently rendered only that row's response, and (more
subtly) every subsequent row's delta-slicing bookkeeping was computed
against the wrong running total (0 instead of the row's real turn
count), which would have corrupted the rest of the reconstruction too
for any longer chain built on top of a truncated row.
Fix: buildMultiRowConversation now detects a truncated request body via
its messageCount field, uses that count for delta bookkeeping instead of
silently treating it as zero, and renders one explicit placeholder turn
("N messages not shown — the request body was too large to log")
instead of just disappearing.
Test plan:
- New regression tests for the truncation case (single truncated row, and
a truncated row followed by a real row to verify bookkeeping stays
correct)
- npm run check:migration-numbering / check:file-size — clean
- npm run typecheck:core / npm run lint — clean
- npm run test:unit — 27086 tests, only 4 failures remain (down from 18 —
2 were fixed by the newer upstream commits pulled in by this re-rebase),
all independently pre-existing/unrelated (ServiceSupervisor timing,
monaco-editor path, npm-pack)
- npm run test:vitest — 291/291 passed
Two independent bugs found during further live verification of the
conversation-tracking feature:
1. (#9315) The dashboard's "Provider Response" panel showed a stale,
incomplete snapshot for long streamed responses. Root cause:
open-sse/utils/stream.ts reconstructed the summary from
buildStreamSummaryFromEvents(providerPayloadCollector.getEvents(), ...)
— but getEvents() only returns whatever survived the collector's
maxEvents/maxBytes cap, so once a stream exceeded it (easy with a
reasoning + tool-calling model), everything after the cutoff (final
finish_reason, tool_calls, rest of reasoning_content, usage) was
silently dropped from the reconstruction, even though the client
actually received the correct, complete response.
Fix: streamPayloadCollector.ts's per-format summary builders
(buildOpenAISummary/buildResponsesSummary/buildClaudeSummary/
buildGeminiSummary) are now also available as incremental reducers
(createXReducer: ingest one chunk at a time, finalize at the end).
createStructuredSSECollector accepts a format + fallbackModel and feeds
the reducer on every push() — including chunks that get dropped from
the retained event array once the cap is hit — via a new getSummary()
method. stream.ts's 3 call sites now use collector.getSummary() instead
of reconstructing from the (possibly truncated) getEvents().
2. Conversation continuation never actually worked for real agentic CLI
traffic. Root cause: computeFingerprintHash/hashTurnsBounded anchored
conversation identity partly on the system message's text — but real
coding-agent CLIs (Claude Code, opencode, etc.) commonly regenerate the
system prompt on every single request with live context (timestamp,
cwd, git status...). That volatility alone broke both the fingerprint
bucket lookup and the prefix-hash continuation check, so every request
minted a brand new conversation id even though apiKeyId/model/toolNames
and the actual user/assistant history were an unbroken, growing
continuation. Confirmed live: 28 consecutive requests from one real,
growing session, each recorded as its own turn_count=1 conversation —
which is also why /dashboard/conversations appeared empty (nothing ever
reached turn_count >= 2) and why an individual timeline/log entry only
ever showed a single turn.
Fix: both computeFingerprintHash's identity anchor and
hashTurnsBounded's head/tail projection now exclude the system message
entirely, so a regenerated-every-turn system prompt can no longer break
continuation detection. New regression test reproduces the exact
scenario (system prompt differs each turn, everything else constant)
and confirms the second request is now recognized as a continuation.
Also fixed while touching hashTurnsBounded: an accidental stray control
character (SOH, 0x01) in the internal join() separator — cosmetic (any
consistent separator produces a valid hash) but worth cleaning up since it
was already being edited; no stored data depended on the old format since
the continuation bug meant turn_count never reached 2 in production.
Test plan:
- New TDD regression tests for both bugs (stream-payload-collector.test.ts,
conversationTracker.test.ts), confirmed failing before the fix and
passing after
- npm run typecheck:core / npm run lint — clean
- npm run test:unit — 26983 tests, 18 failures, all independently confirmed
pre-existing on release/v3.8.50 (reproduced identically against the
clean base commit)
- npm run test:vitest — 291/291 passed
- Rebuilt and redeployed to omniroute-dev; health check + DB migration
verified
Missing title/version/lastUpdated frontmatter broke the Next.js/fumadocs
build entirely (Turbopack: "invalid frontmatter... expected string, received
undefined"), pre-existing on release/v3.8.50 as of #9323 and unrelated to
this branch's feature work — discovered because it blocked building this
branch's image for deploy.
The new "Conversations" sidebar entry and "Conversation" logs column needed
their Vietnamese strings (Vietnamese is the reference locale requiring full
translation, no __MISSING__ placeholders) and the sidebar structure
assertions needed the new item added to their expected lists.
Every agentic chat request now gets a conversation id (X-ConversationId
response header), and OmniRoute detects when a follow-up request continues
the same conversation via fingerprint + bounded prefix-hash matching, with a
strict-growth invariant to prevent false merges between independent
single-shot requests.
Dashboard changes:
- /dashboard/logs: toggleable Conversation column
- /dashboard/logs/timeline: same-conversation requests share a timeline lane,
connected by an arrow, with a configurable lane-reuse window
- Request detail panel: new "Full Conversation" transcript above the raw SSE
event stream, with Markdown rendering, per-turn timestamps, turn-relative
view (only turns up to the one you opened, with a jump-to-next link),
click-any-turn-to-open-its-log navigation, and live auto-refresh (with an
auto-follow toggle, matching the event stream's autoscroll pattern) that
rebuilds the transcript in real time from the in-flight SSE chunk buffer
while a request is still streaming
- New /dashboard/conversations page listing only conversations with 2+ turns
- Configurable auto-refresh intervals on both the timeline and conversations
list pages
Also fixes a pre-existing bug where the timeline view never showed SSE/
stream-chunk events or respected email-masking, because RequestTimeline.tsx
hardcoded debugEnabled/emailsVisible instead of reading the same
server-side/store state RequestLoggerV2.tsx already used, and makes the
request detail panel and conversations list responsive on mobile.
Bumps ip-address, hono, fast-uri, socket.io-parser, undici (v6+v7),
protobufjs, and tar via targeted package.json overrides.
All patches are lockfile-only (no code change, range already covers).
Verified: npm audit → 0 vulnerabilities.
Note: brace-expansion NOT in overrides (separate major lines need
different patches; each resolved within its parent range).
Co-authored-by: wgordon17 <22222756+wgordon17@users.noreply.github.com>
* chore(ci): stop dependabot from grouping ioredis majors with routine bumps
ioredis is loaded through a dynamic import in the distributed quota store, so a
breaking major passes build, typecheck and both test suites and only surfaces at
runtime for operators running Redis-backed quota. #9310 grouped ioredis 5.10.1 to
6.0.0 with 9 unrelated production bumps; majors get their own PR from now on.
* docs(changelog): add fragment for #9425
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(resilience): count STREAM_EARLY_EOF as a provider failure in combo routing
A STREAM_EARLY_EOF is an upstream that accepted the request (HTTP 200), opened
the SSE stream, then closed it without emitting a single non-ping event. The
combo path classified it together with STREAM_READINESS_TIMEOUT through
isStreamReadinessFailureErrorBody(), and the readiness exemption in
shouldRecordProviderBreakerFailure meant the whole-provider circuit breaker
never saw it.
During a provider-wide outage that makes the breaker blind. Over a 7-day window
on our router we recorded 311 of these events, 302 of them on one model, 265
inside the upstream's published incident window — and the provider breaker sat
at CLOSED / failure_count=0 the entire time. Every request kept being dispatched
to the failing provider instead of shedding to the next combo target.
The two codes are different signals. The readiness probe is a pre-flight
liveness check on a connection we have not committed to, so failing it means
"this connection looks stale". An early EOF means the provider took the request
and then failed to serve it. The single-model path already treats it that way:
shouldTripProviderBreakerForResult has no readiness exemption, so a 502 early
EOF trips the breaker there. This makes the combo path consistent.
isStreamReadinessFailureErrorBody keeps matching both codes, because the
transient-retry and round-robin semaphore-cooldown paths in combo.ts do want
identical treatment for both. Only the breaker needs to tell them apart, so the
distinction is added as a narrow predicate and an optional argument rather than
by changing the shared classifier. Omitting the new argument reproduces the
previous behaviour exactly.
Follows the additive-override pattern established by the isProxyUnreachable
work, and leaves the existing exclusions for client aborts and plain 429s
untouched.
* test: register stream-early-eof-breaker in stryker tap.testFiles
The mutation test-coverage gate (check:mutation-test-coverage --strict)
detects unit tests that cover a mutated module but are missing from
stryker.conf.json tap.testFiles, so their mutant kills would not count.
comboPredicates.ts is one of the mutated modules, and the new
stream-early-eof-breaker.test.ts covers it, so the gate correctly flagged
the omission. 8376-econnrefused-breaker.test.ts -- the test this one is
modeled on -- is already registered; this just brings the new file in line.
No production code change.
---------
Co-authored-by: Nick Sullivan <nick@technick.ai>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
The local vi.mock("next-intl") predates the #7935 global polyfill and returns a
useTranslations without .rich, crashing t.rich() in ProviderParamFilterSection:199.
The global polyfill (backed by the real createTranslator) now covers this file;
assertions only check DOM/fetch, never translated text.
Co-authored-by: Max <maxmad64@gmail.com>
* fix(dashboard): add per-connection autoSync toggle handler
* fix(dashboard): render per-connection autoSync toggle in ConnectionRow
* fix(dashboard): wire canAutoSync into ConnectionsListPanel
* fix(dashboard): wire per-connection autoSync toggle into provider page
* fix(dashboard): make master autoSync toggle all-on with fan-out
* docs(dashboard): add changelog fragment for per-connection autoSync
* fix(dashboard): correct disable toast and assert fan-out classification
* test(dashboard): pin fan-out classification branches symmetrically
* docs(dashboard): fill changelog fragment with PR number
* fix(dashboard): port autoSync i18n keys to vi and pt-BR locales
* fix(dashboard): localize autoSync keys across all 43 locales
---------
Co-authored-by: Max <maxmad64@gmail.com>
#9275 started appending a candidate-alias hint to the zero-active-credentials
error and terminated the provider name with a period, so the two sentences read
as one message. The two vscode tokenized-route tests still assert the old
unterminated string and now fail on every pull request opened against this
branch.
The Quality Gates workflow only runs on pull_request to release/**, never on
push, so the branch itself never re-runs these shards and the drift stayed
invisible after the merge.
Assert what the handler actually produces. Keeping the comparison exact rather
than loosening it to a prefix match is deliberate -- the exact form is what
caught the drift.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* fix(routing): only let Codex-native bare ids preempt a provider when codex is active
#9275 widened CODEX_NATIVE_UNPREFIXED_MODELS from a single id to gpt-5.5 plus the
gpt-5.6-sol/terra/luna tiers, so bare Codex CLI ids would reach the ChatGPT
subscription instead of fanning out to whichever provider won the inference race.
The early return it added never consulted the active-provider set, which made the
codex-only guard 30 lines below unreachable for every id in the set:
if (CODEX_NATIVE_UNPREFIXED_MODELS.has(modelId)) return { provider: "codex", ... }
An OpenAI-only install therefore had bare gpt-5.5 routed to codex and failed with
'no active credentials for provider: codex' on a model OpenAI serves, and an install
whose codex connection was merely inactive failed identically. This also silently
reverted #5887's compatibility boundary.
The preference now only PREEMPTS another provider when a codex connection is active.
Ids that no other provider catalogs (codex-auto-review) still resolve to codex with no
connection at all — there is nothing to preempt and 'no codex credentials' is the
honest error. With codex active the preference still beats OpenAI, which is the point
of #9275, and an explicit openai/ prefix overrides it either way.
Tests: the three assertions that encode the intended #9275 change now expect codex
(plus a new one pinning the explicit-prefix override); the rest were already correct
and pass again untouched. Adds a regression test for the OpenAI-only case.
* docs(changelog): correct fragment id to #9447
* test(routing): seed an active codex connection in the bare-precedence guards
The two files #9275 added assert that bare gpt-5.5 / gpt-5.6-sol reach codex, but
they ran against an empty database — so they also pinned 'codex wins with no codex
connection at all', which is the regression #9447 removes. That put them in direct
contradiction with plan3-p0 / chat-helpers / codex-gpt55-routing-5887, which assert
openai for the very same input: no implementation could satisfy both, which is why
the release could not go green.
Seeding an active codex connection keeps the contract these files were written to
guard (codex beats openai for a Codex-native bare id) while dropping the accidental
'even with no codex configured' half. Cases that need no connection are left as they
were: the tier-only ids and codex-auto-review have no alternative provider to preempt,
and the explicit-prefix overrides are unaffected.
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* feat(providers): filter detail connections server-side
Filter provider detail requests at the database boundary while preserving
the full per-provider connection set needed by search, pagination, and bulk
actions. Alias-backed provider pages keep their existing aggregate behavior.
Co-authored-by: RobertsXML <RobertsXML@proton.me>
Inspired-by: https://github.com/decolua/9router/pull/2998
* chore(changelog): fragment for #9247
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: RobertsXML <RobertsXML@proton.me>
* fix(db): persist account egress IP into proxy_logs
The account egress IP (outbound IP the upstream saw, resolved via proxyEgress.ts
echo-IP probe with 5-min cache) was computed and surfaced in the proxy_logs
console and ring buffer, but never persisted: proxy_logs.egress_ip did not
exist, so the value was lost on restart and real traffic could not be
attributed to the node/IP active at that instant.
- migration 134 adds proxy_logs.egress_ip (nullable, backward-compatible)
- schemaColumns.ensureProxyLogsColumns() idempotent reconciler
- proxyLogger self-heals the schema in loadFromDb(), persists egress_ip on
INSERT, and matches it in search
Follows the session_tag (#8249) migration + schemaColumns reconciler pattern;
base SCHEMA_SQL untouched.
* docs(changelog): add 9291 fragment for proxy_logs egress_ip
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Root cause: a cold GET /v1/models catalog rebuild froze the entire server 41-54s.
node --prof profiling found a systemic missing-memoization pattern — a per-model
function rescanning a static or synced data structure with Object.entries()/
Object.keys() (or hitting SQLite) on every call instead of once per rebuild. Fixed
6 instances of the same pattern, found by iteratively re-profiling the full catalog
sweep after each fix (plus a whitebox review pass) until no further hotspot of this
shape remained:
1. getModelsDevPricing() (modelsDevSync.ts) — re-ran a synchronous SQLite query and
re-JSON.parse'd ~180 blobs on every call (up to ~6091x instead of once per
request). Memoized via the existing modelCatalogCacheVersion invalidation signal
(same pattern as getCachedRawProviderConnections/getCachedProviderNodes in
db/readCache.ts). Dominant cost of the original 41-54s freeze.
2. findInsensitive() (modelMetadataRegistry.ts, resolveCatalogPricing) — rebuilt a
full Object.entries() scan on every case-insensitive lookup miss, twice per
model. Replaced with a lowercase-key index built once per distinct pricing
object and cached by identity (WeakMap). Warns once at index-build time on a
case-insensitive key collision instead of silently discarding the second value.
3. getSyncedCapability() (modelsDevSync.ts) — ran a per-model SQLite SELECT on cold
cache instead of self-warming the whole-table cache; no caller in the
/v1/models build path ever primed it, so a cold rebuild ran one SQLite
round-trip per model per call site. Now self-warms via the existing bulk
getSyncedCapabilities() on first miss. Measured as the dominant remaining cost
after fixes 1-2 (~70% of a full catalog sweep).
4. getCanonicalModelSpecId() (shared/constants/modelSpecs.ts) — up to 3 separate
linear scans over the static MODEL_SPECS table per call (exact ci, alias ci,
prefix). Replaced with a lazy, lowercase-key index built once (MODEL_SPECS never
changes at runtime); prefix-match iteration order preserved exactly so
resolution outcomes are unchanged.
5. getStaticSpecCanonicalModelId() (modelCapabilities.ts) — duplicated the same
exact+alias scan as (4) in a second, separate rescan. Now reuses the shared
index via a new exported helper (findModelSpecIdByExactOrAlias) instead of
maintaining a second cache over the same static table.
reverseModelsDevProviders() (modelCapabilities.ts) — rescanned
Object.entries(MODELS_DEV_PROVIDER_MAP) (also static) on every call; memoized
by provider key. Result is frozen (readonly) since it is now shared across
calls instead of freshly allocated each time.
6. resolveModelAlias() (shared/constants/modelSpecs.ts) — rescanned
Object.entries(MODEL_SPECS) unconditionally once per model (verified 1:1 call
ratio, no short-circuit). Case-sensitive exact match (Array.includes(), no
.toLowerCase()) — uses a dedicated exact-match index, deliberately not the
case-insensitive alias index from fix 4/5 (would silently broaden matches).
Measured on a 1940-pair real-catalog sample (static PROVIDER_MODELS registry):
cold sweep 828ms -> 356ms after fixes 3-5 on top of 1-2, extrapolating to roughly
1s on the real ~6091-model catalog, down from the original 41-54s freeze.
Complementary to the stale-serve fix in #8801 (upstream) — neither alone
eliminates the freeze.
Tests: call-count regression guards for every fix (DB prepare / Object.entries /
Object.keys call counts staying constant instead of scaling with iteration count),
plus correctness coverage for case-insensitive/case-sensitive resolution. All
pre-existing consumer suites re-verified passing (96 tests total across 19 files).
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(token-refresh): exempt transient errors from exponential backoff
A refresh that failed on a network timeout was treated exactly like one
that failed on a revoked token: the streak incremented and the circuit
backed off exponentially, up to four hours. A brief upstream blip could
therefore park a healthy account for the rest of the day.
Transient failures now take a flat two-minute retry window instead of
advancing the streak. Classification checks structured signals first
(err.name for AbortError/TimeoutError, then err.code and err.cause.code)
and only falls back to matching the message text, so it does not depend
on upstream wording. Everything else keeps the existing exponential path.
Two properties worth preserving on sight:
- A transient failure never shortens a longer permanent backoff. The
new window is only adopted when the existing one is not already
further out.
- testStatus is preserved on both paths, so a connection whose access
token is still valid keeps serving requests while its refresh
retries.
Only a successful refresh clears the circuit. A successful request does
not, because requests do not refresh tokens.
* chore(quality): rebaseline file-size for tokenHealthCheck.ts
src/lib/tokenHealthCheck.ts lands at 1021 lines, above the 1000 cap. The
file consolidates token-refresh health checking that was previously split
across auth.ts and tokenRefresh.ts, and the refresh circuit state machine
does not divide cleanly, so splitting it to satisfy the cap would cost
more than it buys.
Scoped to this file only. Baseline entries for files this branch does not
touch are left at their upstream values.
Image and video payloads vary by provider and base64 encoding adds substantial overhead. Exempt media routes from OmniRoute's global request-body cap so provider-specific validation determines whether a request is too large. Keep finite body limits for non-media routes and cover both header and streamed-body admission paths.
The claude->openai translator was unconditionally rewriting max to xhigh, which broke any OpenAI-shape upstream that accepts max literally (e.g. ollama-cloud, opencode-go deepseek, moonshot k3, native Claude). Provider-aware effort policy is owned by sanitizeReasoningEffortForProvider in the executor; the translator should only do form conversion.
Regression guard: tests/unit/base-executor-sanitize-effort.test.ts end-to-end case (claude -> ollama-cloud preserves max).
Modal-hosted OpenAI-compatible endpoints (self-hosted Kimi K3 via
Modal free tier) return HTTP 429 with body {"error":"usage limit
reached"} when the account's credit is exhausted. Previously no
QUOTA_PATTERNS regex matched this bare-string error shape, so the 429
fell through to rate_limit (60s short cooldown). Combined with combo
round-robin's per-conversation session stickiness (#3825), this kept
re-targeting the same exhausted connection every turn instead of
locking it out and failing over to an account with remaining credit.
Add a substring pattern matching the JSON key/value pair
"error":"usage limit reached" with tolerance for trailing
punctuation and whitespace. Only the exact "error" key matches;
different keys or qualified transient messages like "Per-minute usage
limit reached" stay classified as rate_limit.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
getCombos() SELECT was missing the id column, so returned combo objects
had their id come only from the JSON data blob. If the data blob lacked
an id field, callers (including the Dashboard) saw null — making the
combo appear to have no primary key and impossible to delete.
Add id to the SELECT so the database column value is always available.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
