Root cause: validateOpenAICompatibleProvider's chat-completions probe fallback treated ANY 4xx other than 401/403/429/400 as a silent 'credentials valid' pass with no warning, so a bogus/non-standard model id (e.g. Featherless/OpenRouter vendor/model typos) went undetected at Check time. The first real request then hit the upstream 404 model_not_found and the per-model lockout, holding the model unavailable for the configured reset window with no prior indication anything was wrong.
User-visible effect: 'Check' now returns valid:true with an explicit warning (including the upstream error message when parseable) whenever the chat probe answers 404, so a bad model id is caught before it reaches production traffic and the lockout.
Reported-by: advane204f (https://github.com/decolua/9router/issues/2032)
Root cause: SmartCrusher's system-message guard only excluded role === "system", but Codex CLI (open-sse/executors/codex.ts) sends its instructions/tool-schema turn with role "developer" (the Responses-API equivalent of system used by newer models). Every other system-exclusion guard in this codebase also covers developer (roleNormalizer.ts, contextManager.ts, claudeUpstreamMessages.ts, etc.) except this one, so Headroom happily tabular-compacted JSON arrays embedded in the developer turn (e.g. an update_plan tool schema example), corrupting the instructions the model needs to call the plan tool and breaking Codex CLI plan mode.
Fix: extend the guard in crushMessages()/collectCompactableArrays() (smartcrusher.ts) to skip role === "developer" alongside role === "system".
Reported-by: SingCJ (https://github.com/decolua/9router/issues/2132)
* fix(codex): strip regex lookaround from tool schema patterns (port from 9router#1556)
Codex/OpenAI's Responses API rejects JSON Schema pattern fields using regex lookaround (e.g. ^(?=.*@).+$) with a 400 'regex lookaround is not supported' error. The existing numeric-field sanitizer (coerceSchemaNumericFields) was only wired into the translated-request path (openai-to-claude.ts), not the native codex/openai passthrough path (normalizeCodexTools in open-sse/executors/codex/tools.ts), so lookahead/lookbehind patterns reached upstream unmodified and broke tool calls for clients that emit them (e.g. IDE agent harnesses validating an email field).
Reported-by: evin (@evinjohnn) (https://github.com/decolua/9router/issues/1556)
* chore(changelog): move #1556 entry to changelog.d fragment
Consistency with the repo's canonical changelog.d/fixes/ workflow (avoids
merge-storm re-conflicts from editing CHANGELOG.md directly).
* refactor(codex): table-drive the regex-strip recursion to keep the complexity ratchet at baseline
The #1556 lookaround strip walked every sub-schema field with its own
copy-pasted if-block (properties / patternProperties / definitions / $defs,
then prefixItems / anyOf / oneOf / allOf), pushing stripUnsupportedRegexPatterns
past the cyclomatic threshold and check:complexity to 2057 > baseline 2056.
Collapse the eight near-identical blocks into two loops over the field-name
constants, with the object-map recursion factored into a helper. Same fields,
same traversal order, same behavior — complexity is back at baseline 2056 and
the #1556 regression tests still pass.
* fix(sse): recognize xiaomi-tokenplan mimo as a thinking-mode model (port from 9router#1321)
The reasoning_content injector already handles DeepSeek/Kimi/K2/MiniMax thinking-mode upstreams, echoing a placeholder reasoning_content on assistant turns that lack one. Its THINKING_MODEL_PATTERNS list omitted the xiaomi-tokenplan mimo family, so requests through xiaomi-tokenplan/mimo-v2.5-pro still hit upstream's 400 'reasoning_content in the thinking mode must be passed back to the API', making the model unusable in multi-turn conversations (e.g. Codex CLI). Add a /\bmimo\b/i pattern so mimo models get the same treatment.
Reported-by: z.wl (@xxue-z) (https://github.com/decolua/9router/issues/1321)
* docs(changelog): add fragment for #7098 mimo thinking-model fix
Cloudflare Workers AI free tier (10k Neurons/day, account-wide) returns
429 with body 'you have used up your daily free allocation of 10,000
neurons' which matched no QUOTA_PATTERNS keyword — falling through to
rate_limit (~60s cooldown) instead of quota_exhausted.
Two layers:
1. Provider-specific rule for 'cloudflare-ai' in providerRuleRegistry
(scope: connection — budget is account-wide, not per-model)
2. Defense-in-depth: /daily free allocation/i in classify429 QUOTA_PATTERNS
Tests: 11/11 pass (provider rule + classify429 paths covered).
Closes#6980
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(6954,6953): preserve system role + strip empty-signature thinking blocks
#6954 — System turns misattributed as assistant (claude-to-openai.ts:352)
The ternary `msg.role === 'user' || msg.role === 'tool' ? 'user' : 'assistant'`
mapped any non-user/non-tool role (including 'system') to 'assistant'.
Mid-conversation system turns (Claude format) lost their role on
translation to OpenAI format, causing them to be treated as assistant
output. Fix: add explicit 'system' branch to the ternary.
#6953 — Empty-signature thinking blocks poison Anthropic leg (openai-to-claude.ts)
Non-Anthropic providers (codex/gpt-5.x) synthesize thinking blocks with
signature:''\. On replay, the old code fabricated a DEFAULT_THINKING_CLAUDE_SIGNATURE
to fill the empty signature — but Anthropic rejects foreign signatures with
HTTP 400, permanently degrading combo/blend routes to codex-only.
Fix: strip thinking blocks with empty/missing signatures and redacted_thinking
blocks with empty/missing data entirely. They carry no replayable value.
Tests: 8 new tests (4 per bug), all passing. Existing #5312 and #5945
regression tests still pass — no interference.
* fix(6953): strip only signature:"" thinking blocks, preserve undefined signature
CI caught a regression: translator-helper-branches test had a Claude-format
thinking block without signature field (undefined) that was being stripped
by the original fix. The fix was too aggressive — it stripped both
signature:"" (non-Anthropic synthesized) and signature: undefined
(legitimate Claude-format).
Correct behavior:
- signature === "" (empty string): strip — hallmark of codex/gpt-5.x block
- signature === undefined: preserve with DEFAULT_THINKING_CLAUDE_SIGNATURE fallback
- redacted_thinking data === "": strip
- redacted_thinking data === undefined: preserve with fallback
Added regression test for undefined-signature preservation.
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Root cause: the STREAMING branch of AntigravityExecutor.executeOnce() had no
!response.ok check at all — it unconditionally wrapped the upstream response
body in a pass-through TransformStream, unlike the sibling non-streaming
branch which already built a sanitized error via buildAntigravityUpstreamError.
When Google's 403 error body was binary/non-UTF8 (observed: gzip-magic-byte
payloads), those raw bytes were forwarded verbatim, corrupting the
client-visible error message ('[ERROR] [403]: <control-byte garbage>').
Fix: add the same !response.ok guard to the streaming branch, routing through
buildAntigravityUpstreamError()/buildErrorBody() (hard rule #12) instead of
piping unknown bytes through as if they were an SSE stream.
Reported-by: Duongkhanhtool (https://github.com/decolua/9router/issues/2461)
The release-green workflow already reproduces the release-equivalent gate
on release/** and opens a tracking issue on HARD failures — but main had
no such watch. Under the parallel-cycle model main only receives merged
work at the release squash, so a gate/infra fix that landed only on the
release branch leaves main red the whole cycle, and repo-wide gates
(CodeQL alert count, ratchet baselines) turn EVERY PR into main red on a
check unrelated to its diff. v3.8.49 hit this 3× in one night.
Adds a dedicated main-green job (push to main + the same 3 crons +
dispatch) that checks out main literally (no resolver, no injection
surface), runs the same validate-release-green.mjs, and opens/updates a
'🔴 main branch not green' issue pointing at the companion-PR fix. Gates
the existing release-green job with an if: so a push to main doesn't
re-validate release and vice-versa; schedule/dispatch sweep both.
Detection backstop for the prevention rule in _shared/merge-gates.md §8.
The E2E mock HTTP server's 500 catch sent error.stack straight to the
response body, which CodeQL flags as js/stack-trace-exposure (medium).
It's test-only localhost code, but the repo-wide CodeQL ratchet counts
open alerts across all branches — so this one alert (baseline 0 → 1)
turned the Quality Ratchet red on EVERY open PR into both main and
release, masking whatever each PR actually changed.
Surface error.message instead: clears the alert, keeps a useful signal
for a failing mock route, and doesn't log to stderr (node:test native
runner corrupts its report stream on console output). The test only
asserts status 200, so the 500 body is not checked.
Introduced by the #7304 integration test added this cycle.
* test(dashboard): dedicated regression guard for #6815 density guarantee
Coverage for the #6815 multi-column density guarantee was only ever
asserted incidentally, by two other guards (#7072, #3520) that pinned the
literal sm:grid-cols-2 token. That coupling evaporated the coverage when
PR #7027 migrated the component to a container-driven auto-fit template
and the literal token was removed from both files.
Adds a dedicated guard that simulates, from the shipped className, how
many columns the per-group card grid renders at a wide container width
-- supporting both the breakpoint-ladder and auto-fit mechanisms this
component has shipped with -- and asserts >1 column, without asserting
any specific Tailwind token.
* chore(changelog): fragment for #7291 density guard
typescript-eslint pins a hard upper bound on its typescript peer
(8.64.0 → ">=4.8.4 <6.1.0"). A major TS bump violates it, so the failure is
not one check — it is the whole toolchain at once.
#7068 is the demonstration: dependabot grouped typescript ^6→^7 with six
harmless dev bumps (@types/node, eslint, fast-check, knip, prettier,
typescript-eslint) and turned Build, Lint, Quality Ratchet, Unit (6/8, 8/8),
Integration (1/2, 2/2) and dast-smoke red in a single PR. The six innocuous
updates were blocked by the one that could never pass.
Ignoring the major lets the rest of the group flow on its own. TS majors are a
toolchain migration and deserve their own PR and their own CI run — not a
weekly automated attempt that cannot succeed until typescript-eslint widens the
peer.
Refs #7068
* fix(stream): reconcile encrypted Codex reasoning visibility without mutating upstream item
Resolves the collision between two open PRs on ensureVisibleResponsesReasoningSummary:
#7095 (xz-dev) found that chat clients see nothing when Codex exposes reasoning
only as encrypted_content, and added a visible placeholder — but did so by
mutating item.summary in place. #7176 (JxnLexn) found that same mutation
corrupts the forwarded response item, discarding the encrypted_content shape
Codex needs for follow-up requests, and removed the mutation — but that also
silently dropped the placeholder, so chat clients went back to seeing nothing.
The mutation existed only so a later line could read the summary text back off
the same item. getVisibleResponsesReasoningSummaryText() computes that text
without touching the item, so:
- synthetic response.reasoning_summary_text.delta / .part.done events still
carry the placeholder for chat clients (#7095's goal), and
- the forwarded response.output_item.done payload keeps its original
encrypted_content intact with no fabricated summary field (#7176's goal).
Applied at both call sites #7095 identified: the native Responses passthrough
in stream.ts/passthroughTailProcessor.ts, and the Responses-to-Chat-Completions
translator in openai-responses.ts.
Closes#7095, closes#7176.
Co-authored-by: Xiangzhe <xiangzhedev@gmail.com>
Co-authored-by: Jan Leon <Jan.gaschler@gmail.com>
* test(stream): guard the encrypted-reasoning mutation via the completed backfill path
The output_item.done line is echoed verbatim on the wire, so a re-introduced
item.summary mutation does NOT surface in that event — verified by re-injecting
the mutation, which left the existing assertion green. The mutation does surface
in the response.completed snapshot, where the captured reasoning item is
re-serialized when upstream sends an empty output (store: false).
Adds that case, which fails as expected when the mutation is re-introduced,
making the #7176 half of the reconciliation an enforced regression guard rather
than an incidental property of the current code path.
Co-authored-by: Xiangzhe <xiangzhedev@gmail.com>
Co-authored-by: Jan Leon <Jan.gaschler@gmail.com>
---------
Co-authored-by: Xiangzhe <xiangzhedev@gmail.com>
Co-authored-by: Jan Leon <Jan.gaschler@gmail.com>
The Quality Ratchet has been red on main, and not for a regression — the report
says 'OK (57 métricas, 11 melhoraram)'. It fails the --require-tighten step:
✗ coverage.branches: melhorou de 73 para 78.1 (delta 5.1000 > slack 5)
— rode 'npm run quality:ratchet -- --update' e commite o baseline apertado
The gate was asking for this in plain text. The baseline's own note names the
same trigger: 'Apertar via quality:ratchet -- --update a partir do 1o run de
coverage mergeada do CI que popule essas chaves.'
Values are the CI's, not a local run. The baseline warns that a local
test:coverage measures ~68% against the CI's ~76.5% — tightening to local
numbers would write the wrong floor. So this reproduces the CI's exact inputs:
eslint-results + coverage-report artifacts downloaded from the merged-coverage
run on main (29387411665), re-rooted from the runner's paths to the local cwd so
extractModuleCoverage can match CRITICAL_MODULE_PATHS, then quality:collect +
quality:ratchet --update. Collected output matches the CI's report line for
line (branches 78.1, statements/lines 80.8, functions 86.44, chatCore 72.98,
combo 85.42, accountFallback 96.78, auth 92.55).
Verified: no baseline key added or removed (56 before, 56 after) — only the 12
coverage values moved. The 57-vs-56 metric count between the CI's run and a
local one is --allow-missing skipping the metrics only CI collects (mutation
scores, CodeQL, bundle size).
Worth recording why the improvement appeared now: it is real, but it surfaced
because Coverage had been SKIPPED whenever unit shards went red — so the ratchet
was passing trivially over ABSENT data. Fixing the shards on #7300 made coverage
run and the ratchet finally had something to compare.
check-test-masking-selfref-6634.test.ts did git I/O inside a unit test
(`git show origin/main:<file>`), the single most common red across today's
babysit sweep — GitHub-hosted runners use shallow/single-ref checkouts with
no origin/main, so the show fails with "fatal: invalid object name". The
prior hotfix (2e42b8efc, #7174) wrapped it in try/catch + on-demand fetch +
t.skip() on failure, but t.skip() itself trips the PR Test Policy
weakened-assert gate (confirmed today on #7300), and origin/main was the
wrong ref anyway — PRs target release/v3.8.49, not main.
Ported the hermetic version proven on PR #7300 (@growab): read the real
current source of check-test-masking.test.ts from disk instead of diffing
against a git ref, and use an empty-string base (baseTaut/baseExtTaut = 0)
instead of the pre-#6404 git snapshot — this maximizes headTaut - baseTaut,
the strictest input for the exclusion under test, so the guard is exercised
at least as hard as before. No git ref, no skip, no CI-shape dependency.
Verified both directions locally:
- SELF_TEST_FIXTURE_RE neutralized in check-test-masking.mjs -> test FAILS
(10 new bare tautologies + 28 new extended tautologies reported)
- restored -> test PASSES, and the full check-test-masking.test.ts suite
(55 tests) stays green, confirming the #6634 self-referential-fixture
regression this guard exists for is still covered.
Co-authored-by: growab <nekron@icloud.com>
* fix(skills): register cli-skill-collector in the agent-skills catalog (#6294 shipped the dir only)
* chore(skills): regenerate cli-skill-collector SKILL.md via the generator, preserving the #6294 authored workflow in the custom block
* fix(skills): derive coverage totals from the id lists + align remaining count assertions (45 catalog / 21 cli)
* fix(skills): SkillCoverage totals are number, not stale literals
The parallel-cycle model hands the frozen release/vX to the captain and cuts
release/vX+1 for everyone else. Phase 0a.0b step 3 then re-homes every open PR
onto the new cycle — today as a hand-run loop of gh pr edit --base.
Three things make that loop unreliable at exactly the moment it matters:
1. gh pr edit --base FAILS SILENTLY (v3.8.42). It exits 0 and leaves the base
untouched, so every edit needs a gh pr view --json baseRefName read-back.
A human mid-release skips that.
2. gh pr list caps at 30 results by default. A loop written without --limit
re-homes the first 30 of 148 and reports success.
3. Volume: the v3.8.49 freeze had 148 open PRs — roughly 450 API calls across
edit, verify and comment.
The script does the read-back on every PR, uses --limit 300, is idempotent (a
PR already on the next base is skipped, so a resumed release re-runs safely),
refuses to start when the next branch does not exist yet, and exits non-zero
listing any PR whose retarget did not take.
It also prints the reminder that it cannot solve the other half: PRs opened
AFTER it runs. Those need the repo default_branch pointed at the live cycle —
contributors open PRs against the default branch, and while that stays on main
they never target a release branch at all (6 such PRs on 2026-07-15).
classify() is pure and unit-tested: retarget open and draft PRs on the frozen
branch; never touch main (the release PR's own lane), an older shipped release,
or a PR already re-homed.
Refs #7307
* fix: raise main server keepAliveTimeout/headersTimeout above Node's 5s default (#7003)
JetBrains AI Assistant's pooled java.net.http.HttpClient reuses a
keep-alive connection past Node's unconfigured 5_000ms keepAliveTimeout,
hitting a socket the server already tore down and getting 0 response
bytes back ("HTTP/1.1 header parser received no bytes"). Wire a new
getMainServerTimeoutConfig() (mirroring apiBridgeServer's pattern) into
run-next.mjs so the main dashboard/API server raises keepAliveTimeout
to 65s and headersTimeout to 66s by default, both env-overridable.
* fix: wire main-server keepAlive timeouts into standalone/production server path (#7003)
getMainServerTimeoutConfig() was only wired into scripts/dev/run-next.mjs,
the dev-only entry point for `npm run dev`/`npm start`. The server real
end users run — `omniroute serve` (npm-installed CLI), Docker, and
Electron — spawns the standalone Next build's server.js via
run-standalone.mjs, which prefers server-ws.mjs (built verbatim from
scripts/dev/standalone-server-ws.mjs by assembleStandalone.mjs) over the
bare server.js precisely because it wraps http.createServer with
production behavior the bare server lacks. That wrapper never configured
keepAliveTimeout/headersTimeout, so the JetBrains AI Assistant reconnect
bug this issue reports still hit the production entry point after the
first pass of this fix. Wire the same helper into the wrapped server
object there too.
typecheck:core (the only blocking CI typecheck gate) runs against a
curated 27-file allowlist that excludes all src/app/(dashboard) TSX, and
next.config.mjs sets typescript.ignoreBuildErrors: true so next build
never type-checks it either. Orphaned-identifier regressions there (the
exact class fixed in #6625/#6909) were invisible to CI.
Adds tsconfig.typecheck-dashboard.json (extends tsconfig.json, scoped to
src/app/(dashboard)/**/*.ts(x)) plus check:dashboard-typecheck, a gate
script that runs tsc against it and diffs per-file/per-TS-code error
counts against a frozen baseline (config/quality/dashboard-typecheck-baseline.json,
262 pre-existing errors), following the same stale-enforcement allowlist
pattern as check-known-symbols. Only NEW errors beyond the baselined
count fail the gate; wired as a new blocking step in ci.yml (lint job)
and quality.yml (fast-gates).
Regression test (tests/unit/build/check-dashboard-typecheck.test.ts, 8
tests) reproduces the #6625/#6909 orphaned-identifier bug class against
the pure parseTscOutput/diffAgainstBaseline helpers.
* fix: filter hidden custom models out of legacy combo model picker (#7156)
* chore(test): move model-select-modal-hidden-models-7156 test into tests/unit/ui (collector coverage) (#7156)
* fix: stop opencode-go quota lookup defaulting to Z.AI endpoint (#7022)
getOpenCodeGoUsage() defaulted OPENCODE_GO_QUOTA_URL to
https://api.z.ai/api/monitor/usage/quota/limit, a Zhipu AI (Z.AI/GLM)
endpoint unrelated to opencode.ai. Whenever a connection had no
dashboard-scraping config (workspaceId/authCookie), the user's real
OpenCode Go API key was sent as a Bearer token to that third-party host
by default, with no operator opt-in.
Remove the hardcoded default: the quota-by-API-key fetch now only runs
when the operator explicitly sets OMNIROUTE_OPENCODE_GO_QUOTA_URL. With
it unset (the default), getOpenCodeGoUsage() returns a descriptive
message and makes zero outbound calls, since OpenCode Go has no public
quota API.
Also updates .env.example and both EN/zh-CN copies of
docs/reference/ENVIRONMENT.md to drop the stale Z.AI default value and
fix the stale open-sse/services/usage.ts source-file reference.
Regression test: tests/unit/opencode-go-quota-no-zai.test.ts (RED on
current code, GREEN after the fix).
* fix: align opencode-go-usage tests with opt-in quota URL contract (#7022)
The prior commit removed the hardcoded api.z.ai default from
OPENCODE_GO_QUOTA_URL, making the quota-by-API-key path opt-in via
OMNIROUTE_OPENCODE_GO_QUOTA_URL. Six pre-existing tests in
opencode-go-usage.test.ts still asserted the old default-fetch
behavior and the old Z.AI-specific error wording, so they broke.
Set OMNIROUTE_OPENCODE_GO_QUOTA_URL before the module import (the
value is read once at load time) to simulate an operator who opted
in, and update the two error-message assertions to the new generic
wording ("the configured OMNIROUTE_OPENCODE_GO_QUOTA_URL endpoint"
instead of "the Z.AI quota API"). Each test still verifies exactly
the same behavior it did before (invalid key, fetch failure, 200
with auth error in body, invalid JSON, quota shape) — only the
opt-in setup and message wording changed.
* fix: recognize Ollama Cloud session usage-limit 429 as quota-exhausted (#7071)
Ollama Cloud's 5-hour "session" usage-limit 429 body ("you (NAME) have
reached your session usage limit...") was never recognized as
quota-exhausted -- only the sibling "weekly usage limit" wording was
fixed (#6638/#3709). Neither the generic QUOTA_PATTERNS list nor the
dedicated weekly-quota classifier matched the session wording, so
checkFallbackError() fell through to the generic ~3s rate-limit
backoff instead of a long QUOTA_EXHAUSTED cooldown -- combo/LKGP
routing cycled back to the "exhausted" account almost immediately
instead of advancing to the next one.
Adds isSessionUsageLimitText()/buildSessionQuotaFallback() to
quotaTextCooldowns.ts, mirroring the weekly-quota pair, with a 5h
cooldown matching Ollama Cloud's documented session window. Wired
unconditionally into checkFallbackError() next to the weekly check so
apikey-category providers like ollama-cloud are covered.
* chore(test): register issue-7071-ollama-session-quota.test.ts in stryker tap.testFiles (#7071)
acquireVqdHeaders() discarded the upstream HTTP status of the
/duckchat/v1/status call and collapsed every non-2xx response to
{vqd4:null, vqdHash1:null}. execute() then always returned a
hardcoded 503 when the token could not be acquired, regardless of
whether DuckDuckGo actually returned 429 (rate limit), 403, or a
genuine 5xx.
This mattered beyond the confusing error message: per the resilience
contract only 408/500/502/503/504 should trip the whole-provider
circuit breaker, not 429. Mislabeling a real 429 as 503 caused the
entire ddgw/* catalog to get knocked offline for the breaker reset
window instead of a short cooldown.
Now acquireVqdHeaders()/acquireAuthHeaders() thread the real status
and Retry-After header through, and execute() surfaces a genuine 429
(with Retry-After) instead of the hardcoded 503; the 503 fallback is
kept for non-429 failures and network errors.
Regression test: tests/unit/duckduckgo-vqd-429-misclassification-6996.test.ts
The oc registry entry (opencode.ai/zen/v1) hardcoded 6 free-tier model
IDs (minimax-m3-free, minimax-m2.5-free, ling-2.6-1t-free,
trinity-large-preview-free, nemotron-3-super-free, qwen3.6-plus-free)
that were delisted upstream and now return 401 "Model X is not
supported". Live upstream instead offers 4 different free models
(mimo-v2.5-free, hy3-free, nemotron-3-ultra-free, north-mini-code-free)
that were never added to our static catalog.
Swap the 6 delisted IDs for the 4 currently-live ones, confirmed
against https://opencode.ai/zen/v1/chat/completions on 2026-07-14.
Updates two existing tests (minimax-m3-model-registry,
provider-registry-qwen-vision) that asserted the now-delisted
minimax-m3-free was present in the oc catalog — they now assert its
absence, matching the corrected contract.
The dns toggle button called fetch(..., { method: "PUT" }) but
src/app/api/tools/agent-bridge/agents/[id]/dns/route.ts only exports
POST, so Next.js auto-returned 405 on every Start/Stop DNS click.
Fixes the frontend caller to match the documented POST contract
(docs/frameworks/AGENTBRIDGE.md:490) already covered by
tests/unit/agent-bridge-dns-route-validation.test.ts.
Adds a regression test asserting the fetch call uses method: POST.
tlsFetchStreaming() streams the upstream response to a temp file via
tls-client-node's streamOutputPath mode. For a non-SSE, non-2xx response
the native binding resolves with an empty in-memory `body` field even
though the real error bytes were already written to (and peeked from)
the temp file, so genuine Claude 400/403/429/500 error details were
silently discarded and replaced with "no response body".
Fall back to a bounded read of the temp file when the resolved
response's body is empty, and export tlsFetchStreaming for
dependency-injected testing without --experimental-test-module-mocks.
When better-sqlite3/node:sqlite are unavailable and the sql.js WASM
fallback OOMs while probing storage.sqlite, getDbInstance() rethrew
an identical 'Out of memory while probing' error on every call,
forever — unlike the generic-corruption probe-failure path (#6632),
which correctly caps at 3 attempts via the restore-count cycle
breaker. Because the OOM path never renames the file away
(intentional — OOM is not corruption), the existing cap is
structurally unreachable for this branch, so every independent
background poller (BATCH, ProviderLimitsSync, HealthCheck,
ModelSync) kept re-triggering the same failure with no terminal
diagnostic, hanging the app forever.
Adds an independent __omnirouteDbOomFailureCount cycle-breaker
mirroring the existing threshold of 3, throwing a distinct terminal
'Aborting startup' diagnostic after repeated OOM failures instead of
looping. Does not touch the rename/backup safety mechanism.
Reported-by: xHmeyer, mostafa-binesh
test:vitest:ui was advisory/parked with 70 failing tests across 30 files (of
159 total). Triaged by grouping failures by root cause instead of fixing
one-by-one:
- 15 files (use-virtual-list, use-traffic-stream, use-system-proxy-exit-guard,
use-session-recorder, use-resizable-panels, traffic-inspector-page,
timing-i18n, stats-tab, session-recorder-bar, same-context-filter,
historic-session-banner, conversation-tab, conversation-tab-separators,
cli-tools-no-mitm-tab, agent-bridge-server-card-a11y) were authored against
node:test but live under tests/unit/ui/*.test.tsx, which vitest.config.ts
collects but test:unit's glob (only *.test.ts) never does — orphaned. Fixed
by switching their describe/it/beforeEach imports to "vitest".
- jsdom does not implement window.matchMedia, and several dashboard
components read it via useTheme() (directly, or transitively through
ProviderIcon). Added tests/_setup/vitestUiPolyfills.ts (wired into
vitest.config.ts) with a minimal MediaQueryList polyfill — fixed
providerCascadeNode, ProviderIcon-icon-url, CliAgentsPage, playground-studio,
comboLiveStudio, memories-tab, home-topology-hidden, ProxyRegistryManager-tdz.
- playground-build-tab.test.tsx (9 tests) and compressionHub*.test.tsx (2
tests) asserted against pre-redesign UI: BuildTab now sits behind a 3-step
BuildWizard (mode picker -> configure -> run), and CompressionHub is a
Phase-2 thin overview without the old master toggle/mode selector/pipeline
list. Rewrote the build-tab test to drive the wizard, and removed the two
compressionHub.test.tsx assertions already superseded by
compressionHub-active-selector.test.tsx. compressionHub-context-editing.test.tsx
asserted stale Portuguese copy against a component that deliberately uses
literal English strings (documented hydration workaround) — aligned to the
real text.
- search-tools-compare-tab.test.tsx: the D22 4-provider cap documented in
docs/frameworks/SEARCH_TOOLS_STUDIO.md was never implemented in CompareTab —
fixed the component (disable extra toggles + cap selectAll + warning
message) since the test was correct and the component was the bug. Also
fixed an assertion looking for a <table> that never existed (the results
panel is a div-based side-by-side layout).
- CliAgentsPage.test.tsx: the agent-tool catalog grew from 6 to 8 (omp, letta
added) since the test was written — updated the fixture and expected count.
- memories-tab.test.tsx: a call-order-dependent fetch mock
(mockResolvedValueOnce + fallback) broke once MemoriesTab started firing an
immediate health check that raced its 300ms-debounced list fetch — switched
to a URL-keyed mock like the rest of the file.
- home-topology-hidden-4596.test.tsx: useLiveDashboard now runs an async
handshake fetch before opening the WebSocket — stubbed fetch and awaited it.
- same-context-filter.test.tsx: the filter branch moved from
useTrafficStream.applyFilter into the extracted, reusable
matchesTrafficFilter() helper — updated the source-grep target.
- tests/unit/ui/provider-plan-config.test.tsx deleted: it tested
ProviderPlanConfigClient, which tests/unit/quota-plans-route-retired.test.ts
proves was deliberately retired (Plans screen removed).
Result: test:vitest:ui 158/158 files, 870/870 tests passing (was 30 failed /
159, 70 failed / 743). test:vitest (MCP/autoCombo) still green at 28/28,
253/253. Not promoted to blocking in this PR per the task — the owner
promotes after reviewing the green suite.
