mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-17 20:32:25 +03:00
461a02b209ffa4fc7258b5bcecd96009804da9fb
8791 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
diegosouzapw
|
461a02b209 |
chore(providers): reconcile the xKiro counts with the chipotle removal
The branch merged the release tip twice: the first pass carried a stale origin/release/v3.8.51 that predated #13913, so every derived count was computed against a provider that had already been retired. Reconciled against the current tip: - Provider count is 359 (tip 358 after the chipotle/pepper removal, plus xKiro). README, AGENTS.md, llm.txt and its 65 locale mirrors, package.json and the six count-bearing SVGs now carry that number; check:docs-counts passes with no strict drift. - docs/reference/PROVIDER_REFERENCE.md regenerated from the live modules. - RESERVED_PREFIX_COUNT 412 -> 413: xKiro registers id "xkiro" with no separate alias, so it adds exactly one REGISTRY member. |
||
|
diegosouzapw
|
6056c5a5cd |
Merge remote-tracking branch 'origin/release/v3.8.51' into HEAD
# Conflicts: # README.md # config/quality/file-size-baseline.json # docs/diagrams/comparison-table.svg # docs/diagrams/free-tier-budget.svg # docs/diagrams/readme-hero.svg # docs/i18n/am/llm.txt # docs/i18n/ar/llm.txt # docs/i18n/az/llm.txt # docs/i18n/bg/llm.txt # docs/i18n/bn/llm.txt # docs/i18n/cs/llm.txt # docs/i18n/da/llm.txt # docs/i18n/de/llm.txt # docs/i18n/el/llm.txt # docs/i18n/es/llm.txt # docs/i18n/et/llm.txt # docs/i18n/fa/llm.txt # docs/i18n/fi/llm.txt # docs/i18n/fr/llm.txt # docs/i18n/ga/llm.txt # docs/i18n/gu/llm.txt # docs/i18n/ha/llm.txt # docs/i18n/he/llm.txt # docs/i18n/hi/llm.txt # docs/i18n/hr/llm.txt # docs/i18n/hu/llm.txt # docs/i18n/hy/llm.txt # docs/i18n/id/llm.txt # docs/i18n/ig/llm.txt # docs/i18n/it/llm.txt # docs/i18n/ja/llm.txt # docs/i18n/ka/llm.txt # docs/i18n/km/llm.txt # docs/i18n/kn/llm.txt # docs/i18n/ko/llm.txt # docs/i18n/lt/llm.txt # docs/i18n/lv/llm.txt # docs/i18n/ml/llm.txt # docs/i18n/mr/llm.txt # docs/i18n/ms/llm.txt # docs/i18n/mt/llm.txt # docs/i18n/my/llm.txt # docs/i18n/ne/llm.txt # docs/i18n/nl/llm.txt # docs/i18n/no/llm.txt # docs/i18n/or/llm.txt # docs/i18n/pa/llm.txt # docs/i18n/phi/llm.txt # docs/i18n/pl/llm.txt # docs/i18n/pt-BR/llm.txt # docs/i18n/pt/llm.txt # docs/i18n/ro/llm.txt # docs/i18n/ru/llm.txt # docs/i18n/si/llm.txt # docs/i18n/sk/llm.txt # docs/i18n/sl/llm.txt # docs/i18n/sr/llm.txt # docs/i18n/sv/llm.txt # docs/i18n/sw/llm.txt # docs/i18n/ta/llm.txt # docs/i18n/te/llm.txt # docs/i18n/th/llm.txt # docs/i18n/tr/llm.txt # docs/i18n/uk-UA/llm.txt # docs/i18n/ur/llm.txt # docs/i18n/uz/llm.txt # docs/i18n/vi/llm.txt # docs/i18n/yo/llm.txt # docs/i18n/zh-CN/llm.txt # docs/i18n/zh-TW/llm.txt # docs/reference/PROVIDER_REFERENCE.md # docs/screenshots/free-tier-budget-card.svg |
||
|
Diego Rodrigues de Sa e Souza
|
b6975537c1 |
fix(providers): remove the chipotle/pepper provider (#13131) (#13913)
* fix(providers): remove the chipotle/pepper provider (#13131) amelia.chipotle.com (the reverse-engineered Amelia chat-widget backend chipotle/pepper-1 talked to) now returns 404 on every route, including root, from its Azure Application Gateway — confirmed live 2026-09-15. This regressed from a WS handshake timeout (#4037, June 2026) to a fully decommissioned host, so the upstream protocol cannot be fixed. Owner decided to retire the provider entirely (Option B), following the phind/kluster quiet-removal precedent: no REMOVED_PROVIDERS.md entry (reserved for operator takedowns), just a one-line note under FREE_TIERS.md "Removed / no free tier". Removed every surface: executor, registry entry, executors/index.ts and providers/index.ts wiring, noauth provider catalog entry, ProviderIcon generic-fallback set, the autoCombo exclusion-list comment, the chipotle_error code from the sanitizer allowlist, PROVIDER_REFERENCE.md (regenerated), and every doc/test reference. Regression test: tests/unit/issue-13131-chipotle-provider-removed.test.ts asserts the provider is fully gone from the executor registry, the provider REGISTRY and the noauth catalog, and that the executor module no longer resolves — not a live-network repro (flaky/third-party). Several existing tests used "chipotle" only as a generic noAuth-provider example (proxy scoping, error classification, onboarding, fallback text) with no chipotle-specific behavior under test; those were re-pointed at another still-existing noAuth provider (cloudflare-playground / duckduckgo-web) rather than weakened. * test(providers): document the agnes-cn/chipotle count coincidence (#13131) provider-node-reserved-prefix.test.ts's REGISTRY id+alias walk was already red on the base tip (414 vs. expected 412) from agnes-cn (#13399, +id/+alias). Removing chipotle's REGISTRY id/alias in this PR nets it back to 412, making the test pass again without a numeric edit — record why in a comment so it doesn't read as an untracked coincidence later. |
||
|
Diego Rodrigues de Sa e Souza
|
872376bdc1 |
fix(chat): reject null/non-object entries in messages[] (#12643) (#13755)
* fix(chat): reject null/non-object entries in messages[] (#12643) A messages array containing null (or any non-object entry, e.g. [null] or [42]) passed every existing entry guard in chat.ts (#5110/#6402/#6407/#6412) and reached downstream translators/session helpers that read `.role` / `.content` directly off each entry (openai-to-claude.ts, sessionManager.ts, contextManager.ts's fixToolPairs), crashing with a raw TypeError and surfacing as an HTTP 500 instead of a clean 400. The route's Zod schema is intentionally wide (z.array(z.unknown())), so this shape check belongs in the handler's guard chain. Adds one more entry-shape guard clause to the same chokepoint, rejecting the request with a clear 400 before any routing or upstream call. Regression test: tests/unit/chat-messages-entry-objects-12643.test.ts PR #12644 (@soroush5) proposed this exact fix but was closed without merging on 2026-09-12; this re-implements it fresh against the current tip using the same guard shape and error message. Originally-proposed-by: @soroush5 in #12644 Co-authored-by: soroush5 <mrsoroushahmadi@gmail.com> * chore(quality): refix the chat.ts ceiling for the merged tree This branch rebaselined src/sse/handlers/chat.ts against an older tip. After merging the current release tip the combined file is 2520 lines, so the 2500 ceiling no longer covers it. The tip alone is already at 2509 — above the 2500 this PR had frozen — so most of the gap is inherited, not introduced here. This PR's own contribution is the +10 of the messages-entry guard itself. Ceiling refixed at the value the gate reports for the merged tree. --------- Co-authored-by: soroush5 <mrsoroushahmadi@gmail.com> |
||
|
Diego Rodrigues de Sa e Souza
|
d6f720bceb |
feat(i18n): new-key gate rejects __MISSING__ markers; skills translate new keys in parallel (#13996)
On 2026-09-16 eight feature PRs added 61 keys to src/i18n/messages/en.json and stamped `__MISSING__:<en>` into all 65 locales instead of translating. check-new-key-coverage accepted the marker as "the key reached the locale", so nothing blocked the PRs, and the blocking real-translation ratio gate then failed on the release tip for everybody (pt-BR 3.2 % > 2.5 % + 0.5). - scripts/i18n/check-new-key-coverage.mjs: a leaf whose value starts with `__MISSING__:` is judged exactly like an absent leaf; the FAIL message names the marker as the cause and prints the per-locale sync-ui-keys command and the parallel runner. Header/JSDoc updated. - tests/unit/i18n-new-key-coverage.test.ts: "a new key that only carries a __MISSING__ marker is flagged" (was the inverse case, which encoded the old contract); the other six cases unchanged and green. - scripts/i18n/translate-new-keys.sh (+ `npm run i18n:translate-new-keys`): committed, detached-safe runner — flock queue, N workers (default 5), 3 attempts per locale of `sync-ui-keys.mjs --translate-markers --batch-size=40`, per-locale logs/.exit + batch.log/batch.status/batch.rc/batch.pid under _artifacts/i18n-new-keys/, non-zero exit while any locale still carries a marker, refuses to start (exit 2, names the five OMNIROUTE_TRANSLATION_* vars) when the backend env is absent. Reads only the OMNIROUTE_TRANSLATION_* lines of the repo .env; kills nothing, matches nothing by name. - docs: QUALITY_GATES.md (gate table + check-new-key-coverage section) and I18N.md (gate table + "Translating the keys a branch adds" subsection). The implementation/port/merge skills reference the new shared snippet `.agents/skills/_shared/i18n-translate-new-keys.md` (skills repo, separate). |
||
|
Diego Rodrigues de Sa e Souza
|
ceafa55824 |
fix(providers): select and verify the requested gemini-web model/mode before answering (#13381) (#13919)
Root cause: GeminiWebExecutor.execute() opened the identical fixed https://gemini.google.com/app URL and ran the identical Playwright interaction sequence for every advertised gweb/<model> id. `model` was read only AFTER the response was captured, purely to stamp the OpenAI-shaped response — never to influence what was actually clicked/typed, so two different advertised models produced byte-identical automation and the response `model` field was a caller-supplied label, not an observed fact. Fix (owner decision, Option B): a new model -> Gemini UI mode map (open-sse/executors/gemini-web/modeSelection.ts) drives an in-browser selection step before anything is typed — try the mode control, read back the active-mode indicator, and only proceed on a confirmed match. An unconfirmed model, or a requested Extended Thinking control that cannot be confirmed (#13381 follow-up comment), fails closed with 400 unsupported_control_for_provider instead of silently running the account default under the requested label. The selectors involved are UNVALIDATED (no live Gemini account from this checkout) — see the PR's "Selector set is UNVALIDATED" section and the required live smoke. Regression test: tests/unit/issue-13381-gemini-web-model-selection.test.ts |
||
|
Diego Rodrigues de Sa e Souza
|
d8ad12f22d |
docs(agents): advance the documented Bun pin to 1.4.2 (#13946)
#13661 bumped the exact `bun` devDependency (and `@types/bun`) from 1.4.0 to 1.4.2, and #12977 moved the `oven/bun` image to 1.4.2-slim. AGENTS.md still documented 1.4.0, so the guide disagreed with package.json for every agent reading it as authority. Version string only. The surrounding policy is deliberately unchanged: Bun stays confined to the allow-listed gate/generator scripts plus the `test:bun:db` smoke suite, and Node remains the only supported runtime. Operator approved editing this protected surface for this change. |
||
|
initguru
|
b7192b72e2 |
fix(thinking): parse/scrub DSML tool-call markers and recognize adaptive thinking (#12905)
* fix(thinking): recognize adaptive thinking + parse/scrub DSML tool-call markers
Two defects combined to break DeepSeek-V4-Flash turns and raise 502
empty_response on Claude Code autocompact.
Defect 1 — DSML tool-call markers leaked as visible content:
DeepSeek-V4-Flash occasionally emits tool calls in a non-standard DSML
text format using full-width pipes instead of the OpenAI tool_calls JSON.
Two shapes appear in production call logs:
- complete block: <｜DSML｜:Read><path>...</path></｜DSML｜:Read>
- stray closers (truncated call): </｜DSML｜parameter></｜DSML｜invoke>
</｜DSML｜tool_calls>, sometimes trailing a system-prompt echo
The openai-compatible path never parsed these, so the markers leaked to
the client as visible content and the turn ended incomplete.
Fix: add open-sse/utils/dsmlToolCalls.ts — parseDsmlToolCalls() converts
complete DSML blocks into OpenAI tool_calls and strips stray closing
markers from content (streaming-safe via a holdback for partial openers).
Wire it into the response translator before extractXmlInvokeBlocks so
DSML and XML invoke tool calls share the same pending queue.
Defect 2 — adaptive thinking silently suppressed:
A prior inline === 'enabled' check on body.thinking.type silently
suppressed adaptive (the intent Claude Code actually sends), so
reasoning was dropped. The model then emitted DSML tool-call markers
as plain text, producing an incomplete stop finish. Fix: use
hasActiveClaudeThinking() (which recognizes enabled AND adaptive) to
set requestedThinking, thread it through stream.ts and translator
state, and gate thinking block emission on state.requestedThinking
so upstream reasoning_content only relays when the client opted in.
Tests: 29/29 (6 dsml-tool-calls, 5 thinking-active-claude-adapter,
3 translator-resp-dsml-integration, 15 translator-resp-openai-to-claude
incl. requestedThinking suppression regression). typecheck:core clean.
* fix(sse): strip echoed system-prompt preamble + preserve large analysis/summary blocks
DeepSeek-V4 and similar models echo the OMNIROUTE_SYSTEM_INSTRUCTION_APPEND
directive (appended to the system tail by claude-to-openai.ts) and whole chunks
of the system prompt (<analysis>/<system-reminder>/<summary> blocks, prose
reproductions of the superpowers skill section) verbatim at the START of their
reply — the 'system message leak' persisting after the request-side fix.
Add two streaming-safe preamble strippers in directivePreambleStripper.ts:
- createDirectivePreambleStripper(directive): drops a leading reproduction of
the exact configured directive across arbitrary SSE chunk boundaries.
- createSystemPreambleStripper(): removes <analysis>/<system-reminder>/
<summary> echo blocks and known prose heads (Phase B) from the very start
of a stream, only while the stream is still a preamble.
Wire both into openai-to-claude.ts content-delta path: chain the exact-directive
stripper then the system-echo stripper before DSML/XML-invoke parsing, so a
leading system echo is dropped before it reaches the client.
Preserve large blocks (>= SYSTEM_ECHO_THRESHOLD=1000 chars) and blocks with no
trailing content — these are the model's real response (e.g. a Claude Code
autocompact summary), not a short system-echo. Stops the autocompact
empty-response regression where a whole-summary <analysis> block was stripped
to empty (3a8515).
Regression: origin's markdown-boundary feature (bufferedPrefix /
splitMarkdownBoundary, commit
|
||
|
Koosha Paridehpour
|
20f3900889 |
fix(claude-web): add charset=utf-8 to Content-Type headers to fix Arabic/Persian UTF-8 mojibake (#13416) (#13419)
* fix(claude-web): add charset=utf-8 to Content-Type headers to fix Arabic/Persian UTF-8 mojibake Fixes #13416 The Claude Web endpoint and the outer SSE streaming pipeline were returning Content-Type headers without an explicit charset parameter: - stream.ts responseHeaders() returned 'application/json' and 'text/event-stream' without charset - responseHeaders.ts buildStreamingResponseHeaders() returned 'text/event-stream' without charset While RFC 8259 defaults JSON to UTF-8 and the SSE spec defaults text/event-stream to UTF-8, some HTTP clients (notably VS Code Chat on Windows) fall back to ISO-8859-1/Latin-1 when no charset is declared, causing multi-byte UTF-8 characters to appear as mojibake. For example, the Persian word for hello (سلام, UTF-8 bytes D8 B3 D9 84 D8 A7 D9 85) was decoded as Latin-1, producing the garbled output 'سلام'. Fix: - claude-web/stream.ts: append '; charset=utf-8' to the Content-Type header in the responseHeaders() helper, with a guard to avoid double appending if the caller already includes a charset - chatCore/responseHeaders.ts: hardcode 'text/event-stream; charset=utf-8' in buildStreamingResponseHeaders() Tests: - 11 new regression tests in claude-web-utf8-mojibake-13416.test.ts covering Persian, Arabic, mixed-script, emoji, and chunk-boundary-split scenarios across both streaming and buffered response paths - All 7 existing claude-web-stream tests pass - All 13 response header tests pass - All 8 adaptive-admission-lifecycle tests pass * test(sse): confirm streaming charset header and add byte-level UTF-8 repro (#13416) Independently verified the mojibake root cause before trusting the charset fix: OmniRoute's claude-web decoder already reconstructs a Persian/Arabic multi-byte UTF-8 sequence split across a chunk boundary correctly because it decodes with TextDecoder({ stream: true }); a naive per-chunk decode (without stream state) is what actually produces the U+FFFD garbling. Updated the 2 exact Content-Type assertions in chat-pipeline.test.ts to match the new "text/event-stream; charset=utf-8" header, which is already the convention used by the other streaming executors (uc.ts, maxai.ts, codex-app-server.ts, etc). Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Koosha Pari <koosha@phenotype.ai> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Koosha Paridehpour
|
f5ff7c1e1b |
fix(compression): skip RTK dedup and truncation for non-shell tool results (#13521)
* fix(db): union customModels with syncedAvailableModels in dispatch path * fix(compression): skip RTK dedup and truncation for non-shell tool results RTK's line deduplication and truncation were applied to all tool results including non-shell tools (read, grep, glob, edit, write). This collapsed structurally meaningful repeated lines in file content (e.g. JSON closing braces, repeated key names), silently corrupting what the model received. Now skipFilters (set for non-shell tools) and isDocumentLikeRead both gate dedup and truncation, so file content survives byte-identical. Fixes #13388 * fix(compression): restrict RTK truncation skip to document-like reads The non-shell truncation-skip (options.skipFilters) disabled the generic line/char cap for every non-shell tool result, including grep/glob/search output that #4559 deliberately did NOT exempt. Only isDocumentLikeRead now gates the generic truncation cap; the broader skip stays for dedup, which is the operation that actually corrupts structured JSON content. Also drops docs/omniroute-pr-body.md, an out-of-scope file carried by an unrelated commit on this branch, and fixes the regression test's broken relative import (tests/unit/compression -> open-sse is 3 levels up, not 2 — this is why the test file could not even load before this commit), adjusts its truncation fixture to a genuinely document-like (non-JSON) read so it actually exercises the isDocumentLikeRead exemption, and adds a negative case asserting large non-shell grep output still gets truncated by the generic cap. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * test(compression): make the RTK preservation test an actual regression guard The four cases all passed against the tip WITHOUT this branch's fix, so they guarded nothing — the next RTK refactor could reopen #13388 in silence. Two causes, both fixed here: - The fixture's repeated lines were not consecutive, and deduplicateRepeatedLines only collapses consecutive runs, so dedup never ran on it. Replaced with a matrix of identical rows, where collapsing them CORRUPTS the data rather than just reformatting it — which is the damage the fix prevents. - Both central assertions sat inside `if (result.stats)`. With the old fixture the engine reported no stats, so the assertion bodies were skipped entirely and the test passed by doing nothing. They now run unconditionally. Verified in both directions on the current tip: with this branch's fix → tests 4 | pass 4 | fail 0 against the tip's engine → tests 4 | pass 3 | fail 1 ✖ RTK should NOT dedup file content from a non-shell 'read' tool --------- Co-authored-by: Forge <forge@kooshapari.local> Co-authored-by: KooshaPari <kooshapari@users.noreply.github.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Koosha Paridehpour
|
7a0b0c64fb |
fix(compression): track only the recursion path in isStrictlySerializable (#13154) (#13423)
* fix(compression): remove isStrictlySerializable gate that rejects valid bodies (#13154) Fixes #13154 isCompressionWorkerEligible used isStrictlySerializable to pre-validate bodies before posting them to a worker thread. The gate is stricter than structuredClone (which postMessage uses natively), rejecting: - undefined values (common in optional config fields) - Date, Map, Set, Uint8Array, RegExp (all structuredClone-compatible) - Shared (non-cyclic) sub-objects (misread as cycles) This caused compression to fall back to inline execution on the main event loop, blocking every concurrent request for the duration of compression passes — the exact failure mode of #10300. The serializability walk is a slower, buggier duplicate of the check postMessage already performs. Removing it: - Eliminates a recursive walk of the entire body on the main thread - Fixes false rejections that prevent worker offload - Allows the catch block at the call site to properly fall through to inline compression instead of silently shipping uncompressed * fix(compression): track only the recursion path, not the whole tree, in isStrictlySerializable (#13154) Restores the cycle-detection gate instead of removing it: the original bug was a single `seen` set shared across the entire recursion tree, never backtracked, so two sibling branches referencing the SAME non-cyclic sub-object were misread as a cycle. Adding to `seen` before descending and removing it after (try/finally) fixes the false positive while a genuine cycle is still rejected before it ever reaches postMessage/the worker. Also reverts the worker-failure catch in runCompressionAsync back to returning the body uncompressed: a worker timeout means the compression was already too heavy for the worker's own budget, so falling through to run that same heavy compression synchronously on the main event loop defeats the point of offloading it to a worker in the first place. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Koosha Pari <koosha@phenotype.ai> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Koosha Paridehpour
|
9c5d60027e |
fix(api): stream /api/logs/export with row cap to prevent V8 heap OOM (#13123) (#13428)
* fix(api): stream /api/logs/export with row cap to prevent V8 heap OOM (#13123) Fixes #13123 GET /api/logs/export buffered every matching row into a single JSON.stringify call with pretty-printing (null,2), roughly doubling the string size. On tables with tens of thousands of rows this crashed the Node process with a V8 heap OOM, taking the gateway down for minutes. Changes: - Stream the response via ReadableStream, serializing one row at a time so peak memory stays bounded regardless of table size. - Add a configurable row cap (limit query param, default 10000, max 50000) so callers cannot accidentally request unbounded exports. - Remove pretty-printing (callers can pretty-print client-side). - Include cap metadata (capped, limit, totalAvailable) when the cap fires so callers know they received a truncated result. - Preserve backward-compatible response envelope: { count, hours, type, logs, ... }. * fix(api): push the /api/logs/export row cap down into the DB layer (#13123) The route-layer streaming + cap from the previous pass still called exportCallLogsSince()/exportProxyLogsSince(), which hydrated and buffered EVERY matching row (including rows beyond the limit) before the cap was ever applied — peak V8 heap was essentially unchanged. Adds countCallLogsSince()/countProxyLogsSince() (cheap COUNT(*), no row hydration, used for totalAvailable) and iterateCallLogsSince()/ iterateProxyLogsSince() that bound the query with SQL LIMIT and yield/hydrate one row at a time: a generator over a LIMIT-bounded id list for call_logs, and fixed-size LIMIT/OFFSET pages for proxy_logs (the shared SqliteAdapter only exposes run/get/all, not a `.iterate()` cursor, so LIMIT/OFFSET pagination is the available cursor-equivalent without widening that interface across all 4 driver adapters). The route now streams from these instead, so the full matching row set is never buffered. Also moves capped/limit/totalAvailable into the response header instead of only the trailer, so a client consuming the stream incrementally learns about truncation before processing every row. Rewrote the test to call the real route.GET handler against a seeded test database instead of a local reimplementation of the stream builder, so a regression in the route or its DB-layer delegates is actually caught. Documents the pre-existing (now more clearly load-bearing) breaking change in a changelog fragment: `limit` defaults to 10,000 rows, so exports that previously returned everything are silently truncated. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Koosha Pari <koosha@phenotype.ai> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
initguru
|
36df9e505a |
fix(codex): fail fast and release per-account Responses WS leases (#12911)
* fix(codex): fail fast and release per-account Responses WS leases * chore(changelog): add fragment for Codex WS lease fail-fast fix Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * fix(codex): carry the reasoning-rule context through the leased WS path --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Diego Rodrigues de Sa e Souza
|
c3e966eeb9 |
docs(changelog): reconcile the v3.8.51 living section — round 2 (2026-09-15) (#13731)
Second `npm run release:reconcile` pass on `release/v3.8.50..release/v3.8.51` (091589089c..c0f92ec98a, 916 non-merge commits, 877 merged PRs): - fold the 173 changelog.d fragments accumulated since #12971 under `## [3.8.51]` and delete them - generate bullets for the 58 cycle commits that had no fragment (4 features / 42 fixes / 12 maintenance), each with the merged PR link and `— thanks @author` - link 137 fragment bullets to the PR of the commit that added them and credit the author; two prefix/origin mismatches reviewed (#12945→#13392, #13001→#13379, both maintainer rebaselines of other people's PRs) - refresh "Release by the numbers" + Top-25 and regenerate the `### 🙌 Contributors` hall (112 external contributors + maintainer; every non-bot author of the 877 merged PRs present) - closed-PR credit audit for the window: nothing to add (#13215→#13361 and #13059→#13690 are still open, #12998 was independently fixed earlier by #12853); no human co-author trailers, no commits without a PR - resync the 58 i18n CHANGELOG mirrors Gates: check:changelog-integrity OK, check:docs-sync PASS. |
||
|
Diego Rodrigues de Sa e Souza
|
8587665669 |
fix(routing): fail over when Auggie's quota-exhausted text exits clean (#12949) (#13751)
Root cause: when a user's Augment/Auggie quota is exhausted, the local
`auggie` CLI prints its "You have run out of usage for ..." warning to
stdout and exits with code 0. AuggieExecutor treated any clean exit as
a successful completion and wrapped that text as a normal 200 assistant
reply, so combo/fallback routing never saw a failure and kept sending
requests to the same exhausted connection.
Fix: detect the CLI's known quota-exhausted phrasing before wrapping
stdout as a completion. Non-streaming returns a 429 in-band error body
(mirroring blackbox-web.ts's precedent for HTTP-200 in-band errors);
streaming buffers the first ~2KB of stdout, and on a match emits the
existing {error:...} SSE envelope (reusing the #7880 combo quality-gate
detection) instead of forwarding the text as a delta.
Regression test: tests/unit/issue-12949-auggie-quota-exhausted-200.test.ts
|
||
|
Diego Rodrigues de Sa e Souza
|
d92046064e |
fix(api): restore MCP namespace identity on follow-up Responses turns (#12996) (#13769)
Root cause: resolveRequestToolIdentity (the #7936/#9780 seam) only ever
resolved a streamed/non-streamed Responses function_call item's
{namespace, name} from the CURRENT request's own requestToolIdentityMap,
built solely from that request's own tools:[{type:"namespace",...}]
declarations. OmniRoute is a stateless-upstream-by-default proxy for the
Responses API, so nothing persisted namespace identity across separate
top-level HTTP requests in the same Codex/MCP session — a follow-up turn
that relies on previous_response_id/session continuity instead of
re-declaring its namespace tools silently lost the namespace field.
Fix: a deterministic wire-name fallback that splits a flattened
mcp__-namespaced wire name on its last "__" separator (mirroring
flattenNamespaceToolName's own construction), scoped to the mcp__
container-name convention so it cannot misfire on an unrelated flat tool
name that happens to contain "__". Applied symmetrically to the
non-streaming path.
Regression test: tests/unit/issue-12996-responses-streaming-namespace-followup.test.ts
|
||
|
Diego Rodrigues de Sa e Souza
|
d032431a5f |
test(catalog): stop the yield guard from dying on production's build budget (#13906)
tests/unit/9147-catalog-eventloop-yield.test.ts exists to prove the /v1/models builder yields to the event loop while assembling a catalog-scale dataset. It asserts res.status === 200 first, and only then the two checks that carry the invariant: the max event-loop gap and the traversal to the last seeded model. The case did not set CATALOG_BUILD_TIMEOUT_MS, so it inherited production's 8s cold-path budget. When the seeded build overruns that on a loaded runner, getUnifiedModelsResponse answers 503 catalog_build_timeout and the status check fails BEFORE either real assertion runs — the guard goes silently dead exactly when the machine is under the load that would make a pin most visible. CI hit it at 8350ms, right at the bound. Measured on the release tip, pristine file, 3 runs at load ~21: 2 pass with max gaps of 247ms and 180ms, 1 fails with 503 !== 200 — roughly a 1-in-3 flake, and the flake has nothing to do with yielding. Pinning a 120s budget lets the invariant be evaluated. The 800ms gap bound is untouched, and with the budget pinned the builder measures 261ms (idle) to 790ms (loaded) against it — still failing a true pin, which is seconds. Build-latency budgeting is a separate concern from this case. Refs #12732 |
||
|
Diego Rodrigues de Sa e Souza
|
209112df36 |
fix(cli): persist supervisor give-up crash diagnostics to disk (#13538) (#13908)
Root cause: ServerSupervisor.handleExit()'s give-up branch only printed the crash summary/log via console.error(). In --tray/--tray-worker mode this process is launched detached with stdio:"ignore" on Windows and Linux (bin/cli/tray/detachedTray.mjs buildTrayLaunch()), so that output is discarded by the OS and nothing ever explained why the tray + gateway disappeared together. Fix (Part A only, see plan-file for Part B — a restart-on-failure policy, out of scope here): best-effort append the crash summary + buffered log to <DATA_DIR>/server/crash.log, wrapped in try/catch so the write can never block shutdown. Surface the same file from `omniroute doctor`. Regression test: tests/unit/issue-13538-tray-crash-diagnostics-lost.test.ts |
||
|
Diego Rodrigues de Sa e Souza
|
21772f40f3 |
fix(security): generate a random per-install CLI token salt (#13679) (#13909)
Both src/lib/machineToken.ts::getActiveSalt() and its mirror in
bin/cli/utils/cliToken.mjs derived the CLI/management bearer token as
HMAC-SHA256(raw machine-id, salt) with a checked-in literal default salt
("omniroute-cli-auth-v1"). Since /etc/machine-id is commonly world-readable,
any local user who never set OMNIROUTE_CLI_SALT could derive the same
bearer token as the server.
getActiveSalt() now generates a random 64-char-hex salt on first use and
persists it under <DATA_DIR>/cli-token-salt.json (falling back to the
literal only when neither the env override nor a persisted/writable salt
can be established). Both implementations use the same resolution order
and the same wx-flag create-race handling so the CLI and server keep
deriving the same token. OMNIROUTE_CLI_SALT stays the explicit operator
override, unchanged.
Regression test: tests/unit/machine-token-random-salt-13679.test.ts
|
||
|
Diego Rodrigues de Sa e Souza
|
e7b82783f2 |
fix(sse): classify a 2xx body as a disguised upstream failure (#13461) (#13910)
Pollinations and Perplexity-web can answer a genuine failure (expired session, exhausted free-tier credits) with HTTP 200 and a structurally normal completion whose assistant text is just the provider's own error prose. classifyProviderError() only inspects the body for 400/401/402/403/429, and detectMalformedNonStream() only checked structural emptiness, so the error text reached the client as a real answer and combo/auto-fallback never triggered. Adds classifyFakeSuccessBody() in errorClassifier.ts — allowlisted to pollinations/perplexity-web, reusing the existing CREDITS_EXHAUSTED_SIGNALS/ACCOUNT_DEACTIVATED_SIGNALS phrase lists, gated on short content with a dominant signal match — and wires it into detectMalformedNonStream() so the existing malformed-200 / combo-failover path picks it up with no other handler changes. Regression test: tests/unit/diagnostics-fake-success-13461.test.ts |
||
|
Diego Rodrigues de Sa e Souza
|
de369fcc59 |
fix(security): container/Fly REQUIRE_API_KEY posture + free-tier usage leak (#13679) (#13911)
PR E of the #13679 insecure-defaults umbrella (items #6, #7; item #8 analyzed as by-design, no change). The published Docker image and fly.toml shipped without REQUIRE_API_KEY set, so a bare `docker run` (README/QUICK-START one-liners, no --env-file) or a `fly deploy` combined "keyless" with "world-reachable" for the anonymous /v1 LLM proxy. docker-compose.yml already mitigates this via loopback-only binding (#12568) and correctly keeps following the operator's own .env, so it is untouched. The npm/CLI local-first REQUIRE_API_KEY=false default in featureFlagDefinitions.ts is also untouched per the owner's decision. /api/free-tier/summary ships an unconditional Access-Control-Allow-Origin: "*" and always included the operator's own local usedThisMonth/remaining usage regardless of auth — a low-severity info leak to any reachable origin. Both fields are now withheld from unauthenticated callers while the intentionally public catalog data stays served to everyone. The gemini-SSE (openai-to-gemini-sse.ts) sub-finding needed no code change: /v1beta/models/*:streamGenerateContent is already classified CLIENT_API and fronted by clientApiPolicy through src/proxy.ts before the translator ever runs, and its CORS-header echo was already hardened fail-closed by #12573. REQUIRE_API_KEY=true (this PR's container/Fly default) closes the dependency that finding cited. Added a locking regression test confirming this chain. Regression tests: - tests/unit/issue-13679-container-posture-require-api-key.test.ts - tests/unit/issue-13679-free-tier-summary-usage-leak.test.ts - tests/unit/issue-13679-gemini-sse-requires-api-key.test.ts (confirmation) Refs #13679 |
||
|
initguru
|
3e080877f2 |
fix(sse): bound active streams without terminal events (#12913)
* fix(sse): bound active streams without terminal events * fix(sse): derive the active-stream ceiling from the largest registered model budget The watchdog is a hard lifetime cap that never resets on bytes, so a flat 15-minute default killed models the registry already allows to run for 20 minutes (the Codex entries declare timeoutMs: 1_200_000). The default is now that maximum plus a one-minute margin, and a new test re-derives the maximum from the registry so a future larger budget fails the gate instead of silently re-opening the bug. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
initguru
|
4c4d5c7fbe |
fix(resilience): allow maxWaitMs=0 as disable sentinel for execution expiration (#12902)
* fix(resilience): allow maxWaitMs=0 as disable sentinel for execution expiration
maxWaitMs normalization clamped the value to min:1, silently rewriting
an operator's 0 ("disable the limiter-managed execution deadline") into
1 — a 1ms expiration that killed every long-running job instantly. This
broke long-running reasoning models (GLM-5.2 with reasoning.effort=max
spends minutes before the first token, exceeding any practical
maxWaitMs; the TTB safety net is FETCH_TIMEOUT_MS, default 600s).
Fix: lower the floor to min:0 so 0 is preserved as the disable sentinel.
Issue #4165 follow-up.
Tests: 7/7 (resilience-normalize-maxwaitms-disable 5 + rate-limit-
maxwaitms-disable-execution 2). typecheck:core clean.
* fix(resilience): relax requestQueueSettingsSchema.maxWaitMs to allow 0
normalizeRequestQueueSettings already treats maxWaitMs=0 as an explicit
disable sentinel (queue-wait budget off), but the settings API schema
still rejected 0 with min(1), so an operator could never actually reach
the fix through PATCH /api/resilience. executionMaxWaitMs is untouched
(stays min(1) — separate field, separate decision, see #12902 item 4).
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* test(resilience): prove maxWaitMs=0 vs #12715's queue-wait gate behavior
Answers the open technical question from #12902's review: does a
GLOBAL maxWaitMs=0 reintroduce the unbounded-queue regression #12715
fixed (a request hanging ~6min until the client aborts)?
Evidence, exercising the real gate chatCore.ts actually calls
(accountSemaphore.acquireMany({ timeoutMs: requestQueue.maxWaitMs }),
not the Bottleneck reservoir the PR's own tests cover) under real
contention (maxConcurrency=1, two concurrent acquires):
- No: it does not hang. setTimeout(reject, 0) fires on the next
tick, so a second contending request is rejected with
SEMAPHORE_TIMEOUT in low milliseconds, never minutes.
- But it is also not a genuine 'no cap' — an operator setting 0
expecting 'wait as long as it takes' instead gets near-zero
tolerance for even momentary contention on any configured
concurrency gate (global/provider/account). This is a real
asymmetry vs. the Bottleneck reservoir path (where 0 truly means
unbounded) left for the maintainer to decide how to resolve —
not something this pass can decide unilaterally.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: Jihyun Son <jihyun.son@sk.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
|
||
|
Koosha Paridehpour
|
28557418db |
fix(proxy): add combo scope to fail-closed proxy guard (#13551)
* fix(proxy): add combo scope to fail-closed proxy guard (fixes #13469) The hasBlockingProxyAssignment guard only checked account, provider, and global scopes. Combo-scoped proxy assignments were not checked, so a fully dead combo pool fell through to direct egress — leaking the host IP. - Add combo scope to the SQL guard query - Add optional comboName parameter to hasBlockingProxyAssignment - A dead combo pool now blocks egress like the other three scopes * fix(proxy): thread comboName through safeResolveProxy to the combo-scope guard (#13469) hasBlockingProxyAssignment() gained a comboName parameter and a combo-scope SQL clause, but its only caller, safeResolveProxy() in chatHelpers.ts, never passed it — the clause always bound NULL and never matched a real combo scope_id, so a fully dead combo-scoped proxy pool still fell through to direct egress. Thread comboName from handleSingleModelChat (where it is already in scope) through safeResolveProxy into the guard, and add tests covering both the guard predicate and the end-to-end wiring. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Koosha Pari <koosha@phenotype.ai> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Koosha Paridehpour
|
2dae6df518 |
feat(sse): retry transient 5xx backend errors with jitter (global-fallback call site) (#12695) (#13143)
* feat(sse): retry transient 5xx backend errors with jitter (global-fallback call site) (#12695) Per Diego's review feedback on the original PR (which was closed for base drift + over-broad scope): - Helper in tests/unit/ (not open-sse/__tests__) - 7 node:test cases - Drop 429 from retryable set (keep 502/503/504) - 429 must respect the RateLimit-Reset header and be surfaced, not silently retried - Touch ONLY the global-fallback call site in chat.ts - the combo-target loop has its own retry semantics already The wrap uses decorrelated full-jitter exponential backoff (per AWS retry guidance), abort-aware (client disconnect cancels immediately), and respects the AbortSignal via a sleep that throws on abort. Re-cherry-pick: dropped all unrelated drift from the original PR (videoBridgeLog plumbing, forcedConnectionId refactor, comboCheckProvider/ghComboGate, getPassthroughProviders, Moonshot quota fetcher, withSelectedConnectionHeader, classifyProviderBreakerResult, reanchorVideoBridgeRedaction, etc.). chat.ts is now +20/-16 — purely the import + the wrap around handleSingleModelChat in the global-fallback block. Diego should now see a clean, focused diff. Fixes #12695 * fix(sse): address kilo-code-bot review on transientBackendRetry helper Per the review comment on the previous commit: - Jitter formula now matches documented AWS decorrelated jitter (temp = min(cap, random(base, prev*3))) instead of an ad-hoc baseMs + rand*prev*2 approximation - AbortSignal is honoured by the default sleep implementation (was previously only honoured by the loop's pre-attempt check) - 'source' option added to TransientRetryOptions so callers can propagate an observability label (e.g. 'global-fallback') through onRetry Adds 3 tests: - default sleep respects AbortSignal without custom sleep - onRetry receives source label - decorrelated jitter is bounded by capMs 10/10 unit tests pass. --------- Co-authored-by: KooshaPari <kooshapari@users.noreply.github.com> |
||
|
Koosha Paridehpour
|
5455740faa |
fix(compression): log warnings for unreadable settings rows (#13522)
* fix(compression): log warnings for unreadable settings rows getCompressionSettings() silently skipped non-string (BLOB) and invalid-JSON settings rows, making it impossible to diagnose config drift between the panel and the runtime. Now logs a warn-level message for each unreadable row, including the key name and a remediation hint (re-save from the Storage panel). Also warns when the 'engines' row exists but yields no valid toggles, so operators know their panel-configured engines map is being silently replaced by the legacy fallback. Fixes #13456 * test(compression): cover getCompressionSettings warnings for unreadable rows The test for #13456 only asserted a stubbed console.warn recorded a message and never called getCompressionSettings(), so it never exercised the production change. Seed a BLOB row, an invalid-JSON row, and an 'engines' row that isn't a usable object, and assert the resulting warnings; also assert a legitimately empty (but valid) 'engines' map does not warn. Also stop warning on a valid-but-empty 'engines' row: parseStoredEnginesMap returns null both for an unreadable row and for a well-formed {} (an operator who deliberately disabled every engine), so only warn when the stored value isn't a usable object at all. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Koosha Pari <koosha@phenotype.ai> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Diego Rodrigues de Sa e Souza
|
cdcf1d2589 |
fix(i18n): translate the 3,719 __MISSING__ markers eight base PRs added on 2026-09-16 (#13974)
61 keys × 61 locales stamped as __MISSING__ by eight PRs on 2026-09-16 translated with sync-ui-keys --translate-markers; ratio gate green again on the release tip. ⚠️ base-red inherited: #12732 |
||
|
Diego Rodrigues de Sa e Souza
|
0d089e7e39 |
fix(quality): clear the release/v3.8.51 base-reds (#13947)
* fix(quality): clear the release/v3.8.51 base-reds
19 failing unit tests plus the API Route Typecheck and mutation-test-coverage
gates, all reproduced on the clean tip before touching anything.
Ten of the failures share one cause. #13452/#13798 made `*-compatible-*`
buildUrl() refuse a connection with no baseUrl instead of quietly defaulting to
the real OpenAI/Anthropic API — which would ship the operator's stored key to a
public third party. The guard is right; three fixtures still built those
connections unhydrated, and one of them put baseUrl at the top level of
credentials, where the chat path never reads it.
The rest:
- modelDiscovery.ts missed the VertexModelMetadataProvenance cast that its
read-path twin in db/models/synced.ts already had — both written by #12471.
- A provider-test regexp carried raw 0x00/0x1f bytes, which makes git, GitHub
and ripgrep treat the file as binary. Same character class, written
with escapes instead of the bytes themselves.
- #13399 (Agnes AI China) adds "agnes-cn" + "agnescn": the only two provider
prefixes since the count was last set (412 -> 414). Everything else added in
that range is model ids.
- The free-tier budget card SVG was stale (443 -> 452 models); regenerated by
its own script.
- Three new tests were missing from stryker.conf.json tap.testFiles, so the
mutants they kill did not count.
Three guards asserted syntax rather than the invariant they protect, and broke
when the source legitimately changed. Each was re-expressed and then verified by
mutating the source back:
- #2331 required modelEffort to head the rawEffort chain; #13556 deliberately
put the server-selected force rule first. The real invariant is relative —
modelEffort outranks the defaults a client injects — and it still trips when
explicitReasoning is moved ahead of it.
- The OAuth loopback guard matched the isLocalhost arm literally; #9944 added
`&& !opts?.manualLoopback`. It now matches the arm whatever guards it, and
still fails when the hint stops being built.
- The i18n scanner flagged dynamically-built keys — t("effort." + mode) reaches
it as a literal prefix, never a string. It now accepts a prefix that resolves
to a namespace holding messages, and still fails when the namespace is gone.
tests/unit/sse-auth.test.ts (#12080) expected a bare null where #13879 now
returns the key-policy diagnostic — the same sentinel shape the terminal-state
path has used since #12441. The assertion was rewritten to the constraint #12080
actually protects: nothing usable comes back and neither connection leaks. The
contract risk that remains — those sentinels are truthy, and executeWebSearch
treats any truthy value as a credential — is filed as #13945 rather than
widened into this PR.
Refs #13866
* fix(quality): clear the second wave of release/v3.8.51 base-reds
The tip moved 13 commits while the first pass was running and brought its own
reds. All reproduced locally on the merged tree first.
vitest 4.1.11 -> 5.0.0 in the #13661 development-group bump is a major, and
vitest 5 moved `vite` from a dependency to a peerDependency. This repo only ever
declared `vite` under `overrides`, which pins a version but installs nothing, so
`npm ci` stopped providing it and the Vitest job died at startup with
ERR_MODULE_NOT_FOUND. Declared as the devDependency it actually is — the same
^8.0.16 the override already pinned, and what @vitejs/plugin-react asks for as a
peer — and regenerated the lockfile: 684 lines added, none changed.
#12909 filtered a mapped array with `toolCall is JsonRecord`, but the element
type is the tool-call literal or null, and a predicate's type has to be
assignable to the parameter's (TS2677). Narrowed by the element's own type
instead; the literal still satisfies JsonRecord at the return.
#12906 added `|| result.errorCode === "empty_response"` to the stream-failure
condition and Prettier rewrapped it, so the #8928 probe — which located the
branch by an exact four-line string — stopped finding it. It now matches on what
the branch tests rather than how it is typeset, and still fails when the
eviction call is removed.
probe-7293 is the visible half of a real conflict, filed as #13948. #7293 merges
a mid-array system into index 0; #12908, landed later, demotes it to "user" in
place instead. Both target the same constraint and only one can win, and the
combination also reorders: the pre-translation hoist moves the turn forward
expecting it to stay a system message, then the demotion converts it where it
now sits, ahead of the conversation. Choosing between the two strategies is a
product call, not a base-red one, so the test was realigned to assert the half
that protects the caller — the instruction survives, as a user turn — and pins
the current ordering with a pointer to the issue, so the eventual decision shows
up as a deliberate test change instead of a silent regression.
Refs #13866, #13948
* fix(quality): allowlist vite, rebaseline tip growth, drop a dead import
Third pass on the release/v3.8.51 base-reds. Declaring `vite` in the previous
commit was correct but incomplete: check-deps is a human review point against
typosquatting, so a newly declared package has to be vouched for by name.
Recorded in dependency-allowlist.json with why it is needed — the official Vite
build tool, already pinned through overrides, and a required peer of both
vitest 5 and @vitejs/plugin-react. That also turns check-deps.test.ts green.
check-file-size went red on nine files. One is mine: sse-auth.test.ts grew when
the #12080 assertion was rewritten. Three of the four assertions I had added
were redundant with the strict deepEqual that follows them, so they are gone and
the file grows by 4 lines instead of 8; the cap absorbs the rest.
The other eight are production and test files this PR does not touch, grown by
other work and never rebaselined — which is the whole reason a base-red drain
exists. Each is attributed to the commit that grew it: #12906 (chat.ts,
chatHelpers.ts, proxyFetch.ts, stream.ts), #12904 + #12910 (chatCore.ts), and
batch_api.test.ts from the same wave. Two of them predate the wave entirely and
were already over cap on
|
||
|
Diego Rodrigues de Sa e Souza
|
b637350680 |
fix(docs): re-sync the 65 documentation mirror sets; section-level docs pipeline; drift gate blocking (#13940)
1,104 mirrors rewritten over five passes of run-translation on the 22-source core set: the 14 sources edited since their translation, the 322 mirrors that were still English copies, and the frontmatter the old extractor leaked into the newer locales' bodies. The pipeline now caches per-`## `-section hashes and retranslates only changed sections, never reuses a section that is still English, rebuilds English-copy / leaked mirrors even when the source is unchanged, merges the state on save (parallel runs), and the drift gate (scoped to the core set) is blocking. Final audit: 0 stale, 0 English copies, 0 leaked frontmatter across 1,430 core mirrors. ⚠️ base-red inherited: #12732 |
||
|
anhtahaylove
|
cb9740b78d |
fix(adobe-firefly): do not spawn Chrome for CDP warm under test runners (#13289)
The CDP session-warm path gated only on ADOBE_FIREFLY_BROWSER_REFRESH, so a unit test exercising the image-edit route spawned a real headed Chrome. The browser holds an OS handle on its profile directory under DATA_DIR, so teardown that rmSync()s the temp DATA_DIR failed with EPERM on Windows, and the CDP socket kept the runner alive for the full 75s warm timeout. Gate the browser path on the same test-runner detection diskSessionsEnabled() already uses. 8510-adobe-firefly-edits-route: 1 pass/4 fail in 63s -> 4 pass/0 fail in 2.5s. |
||
|
anhtahaylove
|
fde6241d41 |
test: close the database before removing temp DATA_DIR (#13290) (#13292)
* test: close the database before removing temp DATA_DIR (#13290) Tests that set their own DATA_DIR and removed it in test.after() failed on Windows with EPERM: nothing closed the SQLite connection, so the directory still had an open handle and the -shm/-wal sidecars kept it locked. maxRetries could not help because every retry hit the same open handle. Adds tests/_setup/tempDataDir.ts with cleanupTempDataDir()/createTempDataDir(), which close the DB singleton (lazily imported, so tests that never touch the database do not pull in the DB layer) and then remove the directory best-effort. Applies it to the five suites confirmed failing. The helper's own test proves the ordering matters: skipping the close makes it fail with 'cleanup must remove the directory'. * test: close the database before removing temp DATA_DIR (15 more suites) Converts the suites that measurably emitted EPERM during a full run to the shared cleanupTempDataDir helper from #13292. Measured on the same 15 files: base -> 22 fail, 40 EPERM lines branch -> 7 fail, 10 EPERM lines The 7 remaining failures are pre-existing and unrelated to teardown: rtk-learn-discover-routes and executor-map-golden already fail on a clean base (6 and 3 failures respectively). * test: close the database before removing temp DATA_DIR (final 9 suites) Completes the #13290 sweep. Two teardown shapes needed the helper: - after()/t.after() hooks that removed DATA_DIR directly - beforeEach() hooks that wiped DATA_DIR between tests while the previous test's connection was still open. These failed *before* the test body ran, so every test in the file reported the same EPERM path. Three of them already called core.resetDbInstance() right before rmSync and still leaked, which is the product-side connection leak tracked in #13303. Measured per file, EPERM lines now 0 across all nine. Remaining failures are pre-existing on a clean base (firefly 4->1, driverFactory 1, responses-* 1 each) and unrelated to teardown. * test: add the missing cleanupTempDataDir import to two responses suites The previous commit swapped rmSync for cleanupTempDataDir in these two files but did not add the import, so both suites died with ReferenceError: cleanupTempDataDir is not defined before running any test. responses-parse-once-4041: 0 pass / 1 fail -> 4 pass / 0 fail responses-route-early-keepalive-wiring: 0 pass / 1 fail -> 3 pass / 0 fail Both now report 0 EPERM. * test: close SQLite handles in three silently-leaking suites These three suites requested DATA_DIR cleanup but the delete failed on Windows because a SQLite connection was still open. They pass today, so the leak is invisible: they carry state between tests and would surface later as an unrelated-looking assertion, as #13303 already did in the Firefly suite (a 500 instead of a 401). agentbridge-mitm-router-key-6403 and agent-bridge-bypass-flow removed their own temp dir in test.after() without closing the DB first; both now use the shared cleanupTempDataDir helper, which closes the singleton before removing the directory. issue-agent-route-execution is a different case: it has no teardown at all, so the connection stayed open until process exit and the isolateDataDir cleanup hook then hit EPERM. It now closes the DB in test.after(). Verified with a probe on fs.rmSync: all three reported a failed delete before, and zero across three consecutive runs after, while the same probe still reports four leaks in the Firefly suite. * test: remove temp DATA_DIR in five suites that never cleaned up These five suites create their own mkdtemp DATA_DIR, open the SQLite DB and never remove the directory, so every run leaves a storage.sqlite behind in the OS temp dir. Each dir is private to its suite, so this leaked disk space rather than corrupting results - but the churn is pointless. Each now closes the DB and removes its directory through the shared cleanupTempDataDir helper. Verified with an exit-time probe that lists storage.sqlite* still present in DATA_DIR: it fired for these suites before the change and is silent after, with the same test counts (22/14/5/3/3 passing). |
||
|
anhtahaylove
|
0b96fe9dc9 |
fix(combo): retry pre-content streaming failures (#13630)
* fix(combo): retry pre-content streaming failures * fix(combo): allow same-target retry for native-pinned pre-content failures A native Codex turn pin forced maxRetries to 0 unconditionally, which also disabled same-target retries. A pre-content stream failure sends no bytes to the client, so retrying the same pinned target is safe and indistinguishable from a first attempt. Set retries stay disabled so a pinned turn can never fail over to a different target. Adds a regression test covering a pinned turn whose first attempt fails before any content is streamed. * docs(changelog): add fragment for pre-content streaming retry fix Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
initguru
|
8deea62daf |
fix(sse): guard empty tool_calls[] and strip tool_choice without tools (#12901)
Two related schema-compliance fixes for upstreams that enforce the OpenAI
spec strictly (vLLM self-hosted, Kimi-K2.6):
1. Empty tool_calls[] guard: providers like Kimi-K2.6 attach an empty
tool_calls:[] array to every content delta when tools are defined. An
empty array is truthy, so guarding on 'delta.tool_calls' alone called
closeMessage() after the first content delta, closing the message item
prematurely. Subsequent content deltas arrived on a done item and were
dropped by clients (Codex: 'OutputTextDelta without active item'),
leaving only the first text fragment in the output. Guard both
translation paths on 'delta.tool_calls?.length' so closeMessage runs
only when at least one actual tool call is present:
- open-sse/translator/response/openai-responses.ts (chatCore translate path)
- open-sse/transformer/responsesTransformer.ts (/v1/responses direct path)
2. tool_choice schema guard: auxiliary/internal calls (e.g. WebSearch)
legitimately send tool_choice:'auto' with no tools array, and routing
may drop the tools array after the client sent it. vLLM rejects this
combination with a schema 400 ('When using tool_choice, tools must be
set'). Add stripToolChoiceWithoutTools() to targetRequestSanitizer.ts
that removes a dangling tool_choice lacking a usable tools array at
the common dispatch boundary. The guard is OpenAI-spec compliance, not
provider-specific, so it fires regardless of provider.
TDD: tests reproduce both bugs (Red: 5 fail → Green: 31 pass, 0 fail):
- tests/unit/translator-openai-responses-empty-tool-calls.test.ts (2 tests)
- tests/unit/responses-transformer.test.ts (+2 tests, 21 total pass)
- tests/unit/tool-choice-schema-normalization.test.ts (8 tests)
typecheck:core: 0 errors
Co-authored-by: Jihyun Son <jihyun.son@sk.com>
|
||
|
initguru
|
9bc7eb8fd2 |
fix(vision-bridge): nested tool_result images + provider-prefix credential check (#12903)
* fix(vision-bridge): extract/replace images nested inside tool_result content
Claude Code sends tool_result images as {type:"image",source:{base64}}
nested inside a tool_result's content array, not as top-level content
parts. The vision-bridge guardrail's extractImageParts filtered nested
hits out (!p.nested), so these images were silently dropped — a
text-only executor then received a request with no image and returned
HTTP 400.
Port the path-based nested extraction/replace fix:
- MediaPart gains a path field: the key/index chain from
message.content[partIndex] down to the media object itself.
- inspect() tracks the path through recursion; pushPart stamps it.
- extractImageParts drops the !p.nested gate and emits path for nested
hits (extract↔replace contract preserved: same order, every hit
replaceable).
- replaceImageParts rewrites via detectMediaParts: top-level hits swap
their content slot, nested hits walk MediaPart.path via the new
replaceObjectAtPath helper.
- ensureBase64ImagesForClaudeWire skips nested hits (.filter(!p.path))
to keep its sequential index map aligned.
TDD: 7 failing tests (path field, nested extract, nested replace,
document order) → 47/47 pass. typecheck:core clean.
* fix(vision-bridge): resolve provider prefix to node id for credential check
Re-land 932002580 (2026-08-19), which was never merged: it branched off
|
||
|
initguru
|
f3acf4f811 |
fix(sse): inject global system prompt once, post-translation, across all target shapes (#12904)
* fix(sse): inject global system prompt post-translation for codex/Responses path codex/Responses requests carry input[]+instructions, not messages[]. The existing injectSystemPrompt runs PRE-translation (chatCore.ts) and only handles messages[]/system fields, so the Global System Prompt (After Prompt = suffixPrompt) never reached the provider for codex — verified 0/84 call logs while the catalog base_instructions reached 84/84. Add injectSystemPromptPostTranslation() and call it after prepareUpstreamBody on the resolved messages[]. With multiple system/developer messages (codex normalises its per-item developer roles to system), prefix goes on the FIRST and suffix on the LAST so the After Prompt retains the highest recency position — the semantics injectSystemPrompt's single-findIndex buries. Also wire OMNIROUTE_SYSTEM_INSTRUCTION_APPEND on the /v1/messages (Claude Messages -> OpenAI Chat Completions) translation path. The directive was previously only wired on the Responses API path, so DeepSeek-V4 kept leaking English planning/chain-of-thought into the content field on Claude Code sessions that route through /v1/messages. Mirror the openai-responses.ts pattern: append to string system, append a text block for array content, or unshift a new system message when none exists. Tests: 23/23 (19 system-prompt incl. 6 postTranslation + codex regression; 4 claude-to-openai directive append). typecheck:core clean. * test(sse): reproduce global prompt double injection — single-injection contract tests * fix(sse): unify global prompt injection to single post-translation pass * fix(sse): carry single global-prompt injection across claude/gemini/responses target shapes * fix(sse): restore global-prompt coverage for carrier-less targets via gated pre-translation pass * fix(sse): cover codex/gemini source shapes in the carrier-less pre-translation gate * fix(types): preserve generic system prompt return * fix(sse): correct file reference in claude-to-openai.ts comment and add changelog fragment Points the #reasoning-bilingual comment at the real companion file (translator/response/openai-to-claude.ts's directivePreambleStripper.ts from #12905) instead of the nonexistent "openai-responses.ts", and adds the changelog fragment referenced in the PR body but missing from the diff. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Jihyun Son <jihyun.son@sk.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
initguru
|
d70f43d4b4 |
fix(sse): retry empty_response 502 + reasoning-aware direct response-start timeout (#12906)
* fix(sse): retry 0-byte empty_response 502 like STREAM_EARLY_EOF to stop autocompact 502
A genuine 0-byte upstream empty response (GLM-5.2 on a huge autocompact
context returns ONLY reasoning_content or nothing, then closes) reaches
stream.ts::emitClaudeEmptyStreamErrorAndAbort which emits a 502 with
code "empty_response" via the onFailure callback AND propagates the
failure down the pipeline as controller.error(new Error(msg)). The plain
Error carries no .code, so getUpstreamErrorIdentifier (reads only
error.code) returns undefined, result.errorCode/result.errorType become
undefined, and the single-model retry guard (chat.ts) only matches
errorType === "stream_early_eof" / errorCode === "STREAM_EARLY_EOF".
The 502 surfaces to the client with no re-attempt (call logs
1788132529140-96ef4a / 1788142914004-062cf6, ~48s, tokens out=0).
This is the same class of transient upstream glitch STREAM_EARLY_EOF was
built for (HTTP 200 then zero useful frames — #3758), but empty_response
was never wired into the retry path.
Fix (three chokepoints, all required for consistency):
- stream.ts: emitClaudeEmptyStreamErrorAndAbort now propagates an Error
carrying code="empty_response" so a downstream classifier can identify
it (plain new Error(msg) dropped it).
- chatHelpers.ts: shouldRetryStreamEarlyEof now treats "empty_response"
the same as "STREAM_EARLY_EOF" via RETRYABLE_STREAM_EMPTY_CODES Set —
ONE bounded same-connection re-attempt, never a loop
(STREAM_EARLY_EOF_MAX_RETRIES=1 unchanged).
- chat.ts: the single-model retry guard now also enters on
errorCode === "empty_response".
The bounded retry never marks the account unavailable (an empty response
is a transient upstream glitch, not a bad key), mirroring #3758.
Tests: 5/5 (stream-empty-response-retry-96ef4a). Existing 3758 regression
guard stays green (5/5). typecheck:core clean.
* fix(sse): make direct response-start timeout reasoning-aware to stop 504 on high-effort TTFB
Reasoning models (GLM-5.2/5.3 reasoning.effort=high/max, codex-gpt-5.x-high,
third-party Claude-format replicas) warm up with a ~78s+ TTFB before
emitting the first byte. The stream-readiness layer (streamReadinessPolicy)
already budgets 180s for this class, but the fetch-layer guard
(resolveDirectHeadersTimeoutMs) was a flat 30s — it pre-empted a warm
reasoning response the readiness layer would have permitted, surfacing a
504 (regression introduced by
|
||
|
initguru
|
f4be5cc0c7 |
fix(sse): demote mid-conversation system roles to user in claude-to-openai translation (#12908)
* fix(sse): demote mid-conversation system roles to user in claude-to-openai translation Claude Code hook contexts (SessionStart ~25KB, PreToolUse) arrive as role:system messages in the middle of the messages array. HCP-Vision-Latest vLLM (via LiteLLM gateway) rejects any system not at index 0 with 400 "System message must be at the beginning." Demote every system at output index > 0 to user with content preserved byte-identical; the index-0 system (translator-made from the top-level system field, or client-placed first) stays untouched. Other upstreams are unaffected: 135/138 recent mid-system calls to GLM-5.3-Flash / DeepSeek-V4-Flash already returned 200. Supersedes the pass-through assertion of #6954 (its intent — systems never misattributed as assistant — still holds). * test(sse): harden mid-system demotion with env guard and array-path invariant note Quality-review Minor 1: document the array-return-path invariant in claudeToOpenAIRequest (convertClaudeMessage arrays are tool/user only, so no second system element can survive demotion while result.messages is empty). Minor 2: add the same OMNIROUTE_SYSTEM_INSTRUCTION_APPEND env guard to the #6954 test as the new mid-system test for consistency. APPROVED items, no behavior change. --------- Co-authored-by: Jihyun Son <jihyun.son@sk.com> |
||
|
initguru
|
9febe4414d |
fix(compat): preserve GPT and Claude Code tool-call history (#12909)
* fix(compat): preserve GPT and Claude Code tool-call history * docs(changelog): add fragment for tool-call history preservation fix Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
initguru
|
051576fd3d |
fix(usage): finalize semantic cache hits by exact request id (#12910)
* fix(usage): finalize semantic cache hits by exact request id * docs(changelog): add fragment for semantic cache exact-id finalize fix Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
dependabot[bot]
|
602161d7bc |
deps: bump the development group across 1 directory with 15 updates (#13661)
Bumps the development group with 15 updates in the / directory: | Package | From | To | | --- | --- | --- | | [@eslint/compat](https://github.com/eslint/rewrite/tree/HEAD/packages/compat) | `2.1.0` | `2.1.1` | | [@playwright/test](https://github.com/microsoft/playwright) | `1.62.1` | `1.63.0` | | [@testing-library/user-event](https://github.com/testing-library/user-event) | `14.6.6` | `14.6.7` | | [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) | `26.4.0` | `26.5.1` | | [bun](https://github.com/oven-sh/bun) | `1.4.0` | `1.4.2` | | [@types/bun](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/bun) | `1.4.0` | `1.4.2` | | [eslint](https://github.com/eslint/eslint) | `10.9.1` | `10.10.0` | | [eslint-config-next](https://github.com/vercel/next.js/tree/HEAD/packages/eslint-config-next) | `16.3.3` | `16.3.5` | | [fast-check](https://github.com/dubzzz/fast-check/tree/HEAD/packages/fast-check) | `4.9.0` | `4.10.0` | | [knip](https://github.com/webpro-nl/knip/tree/HEAD/packages/knip) | `6.34.0` | `6.35.1` | | [lint-staged](https://github.com/lint-staged/lint-staged) | `17.4.1` | `17.5.1` | | [opencode-ai](https://github.com/anomalyco/opencode) | `1.18.25` | `1.18.30` | | [promptfoo](https://github.com/promptfoo/promptfoo) | `0.122.2` | `0.123.0` | | [typescript-eslint](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/typescript-eslint) | `8.69.0` | `8.70.0` | | [vitest](https://github.com/vitest-dev/vitest/tree/HEAD/packages/vitest) | `4.1.11` | `5.0.0` | Updates `@eslint/compat` from 2.1.0 to 2.1.1 - [Release notes](https://github.com/eslint/rewrite/releases) - [Changelog](https://github.com/eslint/rewrite/blob/main/packages/compat/CHANGELOG.md) - [Commits](https://github.com/eslint/rewrite/commits/compat-v2.1.1/packages/compat) Updates `@playwright/test` from 1.62.1 to 1.63.0 - [Release notes](https://github.com/microsoft/playwright/releases) - [Commits](https://github.com/microsoft/playwright/compare/v1.62.1...v1.63.0) Updates `@testing-library/user-event` from 14.6.6 to 14.6.7 - [Release notes](https://github.com/testing-library/user-event/releases) - [Changelog](https://github.com/testing-library/user-event/blob/main/CHANGELOG.md) - [Commits](https://github.com/testing-library/user-event/compare/v14.6.6...v14.6.7) Updates `@types/node` from 26.4.0 to 26.5.1 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) Updates `bun` from 1.4.0 to 1.4.2 - [Release notes](https://github.com/oven-sh/bun/releases) - [Commits](https://github.com/oven-sh/bun/compare/bun-v1.4.0...bun-v1.4.2) Updates `@types/bun` from 1.4.0 to 1.4.2 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/bun) Updates `eslint` from 10.9.1 to 10.10.0 - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](https://github.com/eslint/eslint/compare/v10.9.1...v10.10.0) Updates `eslint-config-next` from 16.3.3 to 16.3.5 - [Release notes](https://github.com/vercel/next.js/releases) - [Commits](https://github.com/vercel/next.js/commits/v16.3.5/packages/eslint-config-next) Updates `fast-check` from 4.9.0 to 4.10.0 - [Release notes](https://github.com/dubzzz/fast-check/releases) - [Changelog](https://github.com/dubzzz/fast-check/blob/main/packages/fast-check/CHANGELOG.md) - [Commits](https://github.com/dubzzz/fast-check/commits/v4.10.0/packages/fast-check) Updates `knip` from 6.34.0 to 6.35.1 - [Release notes](https://github.com/webpro-nl/knip/releases) - [Commits](https://github.com/webpro-nl/knip/commits/knip@6.35.1/packages/knip) Updates `lint-staged` from 17.4.1 to 17.5.1 - [Release notes](https://github.com/lint-staged/lint-staged/releases) - [Changelog](https://github.com/lint-staged/lint-staged/blob/main/CHANGELOG.md) - [Commits](https://github.com/lint-staged/lint-staged/compare/v17.4.1...v17.5.1) Updates `opencode-ai` from 1.18.25 to 1.18.30 - [Release notes](https://github.com/anomalyco/opencode/releases) - [Commits](https://github.com/anomalyco/opencode/compare/v1.18.25...v1.18.30) Updates `promptfoo` from 0.122.2 to 0.123.0 - [Release notes](https://github.com/promptfoo/promptfoo/releases) - [Changelog](https://github.com/promptfoo/promptfoo/blob/main/CHANGELOG.md) - [Commits](https://github.com/promptfoo/promptfoo/compare/0.122.2...0.123.0) Updates `typescript-eslint` from 8.69.0 to 8.70.0 - [Release notes](https://github.com/typescript-eslint/typescript-eslint/releases) - [Changelog](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/typescript-eslint/CHANGELOG.md) - [Commits](https://github.com/typescript-eslint/typescript-eslint/commits/v8.70.0/packages/typescript-eslint) Updates `vitest` from 4.1.11 to 5.0.0 - [Release notes](https://github.com/vitest-dev/vitest/releases) - [Changelog](https://github.com/vitest-dev/vitest/blob/main/docs/releases.md) - [Commits](https://github.com/vitest-dev/vitest/commits/v5.0.0/packages/vitest) --- updated-dependencies: - dependency-name: "@eslint/compat" dependency-version: 2.1.1 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: "@playwright/test" dependency-version: 1.63.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: "@testing-library/user-event" dependency-version: 14.6.7 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: "@types/bun" dependency-version: 1.4.2 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: "@types/node" dependency-version: 26.5.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: bun dependency-version: 1.4.2 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: eslint dependency-version: 10.10.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: eslint-config-next dependency-version: 16.3.4 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: fast-check dependency-version: 4.10.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: knip dependency-version: 6.35.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: lint-staged dependency-version: 17.5.1 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: opencode-ai dependency-version: 1.18.30 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: development - dependency-name: promptfoo dependency-version: 0.123.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: typescript-eslint dependency-version: 8.70.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: development - dependency-name: vitest dependency-version: 5.0.0 dependency-type: direct:development update-type: version-update:semver-major dependency-group: development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
856051901d |
deps: bump oven/bun from 1.4.0-slim to 1.4.2-slim (#12977)
Bumps oven/bun from 1.4.0-slim to 1.4.2-slim. --- updated-dependencies: - dependency-name: oven/bun dependency-version: 1.4.2-slim dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Diego Rodrigues de Sa e Souza
|
3d5baf13f4 |
fix(providers): strip Vertex doc script blocks whose end tag carries junk (#13936)
The Vertex model-docs HTML is converted to plain text before the table parser reads context-window and token-limit numbers out of the cells. The script/style removal pass required the end tag to be `</script\s*>`, but the HTML spec closes the element on `</script\t\n foo>` too. Such a block survived the pass; the generic `<[^>]+>` strip below then removed both tags and kept the script BODY, so text that only ever existed inside a script became cell text the number parser trusts. Accept any end tag that starts with `</script`/`</style` followed by a tag-name boundary, matching what a browser does. CodeQL js/bad-tag-filter, alert #1007. |
||
|
dependabot[bot]
|
f89e188a9f |
deps: bump js-yaml (#13212)
Merged as-is — single-file lockfile bump in `/electron`, 3 lines, transitive resolution only. js-yaml 4.3.2 hard-limits the merge-sequence size and counts empty mappings toward `maxTotalMergeKeys` (nodeca/js-yaml#797) — CPU-DoS hardening, which is worth taking promptly and carries no API surface change. Verified against the tip before merging: `electron/package-lock.json` is the only file touched. |
||
|
Ravi Tharuma
|
416c736bb9 |
fix(oauth): soft-fail Claude refresh so CredentialHealth is not sticky-dead (#13185)
Merged after boarding with #13426 into one worktree cut from `release/v3.8.51` (both verified as ancestors of the combined HEAD before validating).
**Evidence**
- Your own test plus **every sibling** in the module — 14 files across `tokenHealthCheck*`, `token-health-check*`, `credential-health*` and `issue-13470-token-refresh-proxy-bypass`: **72/72 pass** on the combined tree. Running the siblings and not just the PR's own file is deliberate: this PR changes sweep-path state that several of those files exercise independently.
- Gates: `check-changelog-integrity` PASS, `check-complexity` PASS (2842 vs baseline 3218), `check-cognitive-complexity` PASS (1284 vs 1437), `typecheck:core` PASS.
**Reconciled — one real gate violation, fixed in your branch (
|
||
|
Ravi Tharuma
|
683a552fcb |
fix(opencode-plugin): report disk-cache age in the stale-fallback warning (#13426)
Merged after boarding with #13185 into one worktree cut from `release/v3.8.51` (both verified as ancestors of the combined HEAD before validating). **Evidence** - Full `@omniroute/opencode-plugin` suite — not just this PR's file: **373/373 pass** across all 26 test files. - Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS (2842 vs baseline 3218), `check-cognitive-complexity` PASS (1284 vs 1437), `typecheck:core` PASS. - `check-file-size`: no violation attributable to this PR. **One note for the record.** On a first run the suite reported `scaffold: built ESM default export resolves with the v1 plugin shape` failing with `ERR_MODULE_NOT_FOUND … dist/index.js`. That was a fresh worktree without the plugin built, not a defect in this PR — after `npm run build` in the workspace, all 373 pass. Flagging it because that failure reads exactly like a PR bug and could easily be misattributed to you on a future run. Thanks, @RaviTharuma — putting the snapshot age in the warning turns "using stale disk cache" from a fact into something an operator can act on, and you covered `snapshotAgeLabel` with both the numeric-`writtenAt` and missing-`writtenAt` cases rather than only the happy path. |
||
|
Nguyen Thanh Dat
|
5acac8021d |
fix(redis): namespace warmup circuit-breaker keys with REDIS_KEY_PREFIX (#13328)
The warmup scheduler's circuit-breaker keys were written to Redis without `REDIS_KEY_PREFIX`, so they escaped OmniRoute's namespace and could collide with another app sharing the instance — the one Redis surface the prefix wasn't reaching. Probe: 2/2 pass in `tests/unit/lib/warmupScheduler/redisCircuitBreakerStorePrefix.test.ts`, covering both the prefixed case and the unset/blank case where keys must stay unchanged.
**Batch validation** — boarded with the other 10 PRs of your batch into one worktree cut from `release/v3.8.51`; every PR verified as an ancestor of the combined HEAD before validating.
- Focused tests across all 11 PRs: **104/104 pass** on the combined tree.
- Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS, `check-cognitive-complexity` PASS, `typecheck:core` PASS, `check:open-sse-typecheck` PASS.
- `check-file-size` is red, but reproduces with byte-identical line counts on the pure `release/v3.8.51` tip (`open-sse/handlers/imageGeneration.ts` 3304, `open-sse/services/combo/roundRobinCombo.ts` 1221, `open-sse/utils/stream.ts` 3115). Inherited base-red, nothing added by this batch — it is also why this PR's "Fast Quality Gates" check was red.
**Reconciled** — this PR was `CONFLICTING`. The conflict was in `docs/reference/ENVIRONMENT.md` and purely additive: the release tip had inserted `APP_BIND_HOST` / `QDRANT_BIND_HOST` / `BIFROST_BIND_HOST` rows directly above the `REDIS_KEY_PREFIX` row you edited. Kept both sides — the tip's three new rows and your updated description naming the warmup circuit breaker — then merged the current release branch in (
|
||
|
Nguyen Thanh Dat
|
7ad270ca7a |
fix(translator): send a Claude tool_result image to Gemini as inlineData (#13335)
A Claude `tool_result` carrying an image was not translated into Gemini `inlineData`, so the image was dropped from the conversation. Probe on your head: 3/3 pass. Thanks, @datrixlab. **Batch validation** — boarded with the other 10 PRs of your batch into one worktree cut from `release/v3.8.51`; every PR verified as an ancestor of the combined HEAD before validating. - Focused tests across all 11 PRs: **104/104 pass** on the combined tree. - Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS, `check-cognitive-complexity` PASS, `typecheck:core` PASS, `check:open-sse-typecheck` PASS. - `check-file-size` is red, but reproduces with byte-identical line counts on the pure `release/v3.8.51` tip (`open-sse/handlers/imageGeneration.ts` 3304, `open-sse/services/combo/roundRobinCombo.ts` 1221, `open-sse/utils/stream.ts` 3115). Inherited base-red, nothing added by this batch — it is also why this PR's "Fast Quality Gates" check was red. |
||
|
Nguyen Thanh Dat
|
c1338f1e78 |
fix(translator): pair id-less Gemini tool results with their call (#13334)
Gemini tool results without an id could not be paired with their originating call, so the pairing fell apart on any history that omitted ids. Probe on your head: 24/24 pass across `gemini-tool-result-without-id` and the existing `v1beta-gemini-tool-calling-6222` suite; the combined run reconfirmed both plus the antigravity path. Thanks, @datrixlab — extracting `geminiToolCallIds.ts` as a shared helper instead of duplicating the pairing logic across `gemini-to-openai`, `antigravity-to-openai` and the v1beta converter is what keeps the three from drifting apart later. **Batch validation** — boarded with the other 10 PRs of your batch into one worktree cut from `release/v3.8.51`; every PR verified as an ancestor of the combined HEAD before validating. - Focused tests across all 11 PRs: **104/104 pass** on the combined tree. - Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS, `check-cognitive-complexity` PASS, `typecheck:core` PASS, `check:open-sse-typecheck` PASS. - `check-file-size` is red, but reproduces with byte-identical line counts on the pure `release/v3.8.51` tip (`open-sse/handlers/imageGeneration.ts` 3304, `open-sse/services/combo/roundRobinCombo.ts` 1221, `open-sse/utils/stream.ts` 3115). Inherited base-red, nothing added by this batch — it is also why this PR's "Fast Quality Gates" check was red. |
||
|
Nguyen Thanh Dat
|
84149b93e3 |
fix(translator): keep tool_choice "none" instead of turning it into "auto" (#13333)
Claude accepts `tool_choice: "none"` natively, but the translator was rewriting it to `"auto"` in both directions — a caller explicitly forbidding tool use got tools offered anyway. Probe on your head: 36/36 pass across `translator-openai-to-claude` and `translator-claude-to-openai`. Thanks, @datrixlab — doing both directions in one PR is right; a one-sided fix here would have been worse than none. **Batch validation** — boarded with the other 10 PRs of your batch into one worktree cut from `release/v3.8.51`; every PR verified as an ancestor of the combined HEAD before validating. - Focused tests across all 11 PRs: **104/104 pass** on the combined tree. - Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS, `check-cognitive-complexity` PASS, `typecheck:core` PASS, `check:open-sse-typecheck` PASS. - `check-file-size` is red, but reproduces with byte-identical line counts on the pure `release/v3.8.51` tip (`open-sse/handlers/imageGeneration.ts` 3304, `open-sse/services/combo/roundRobinCombo.ts` 1221, `open-sse/utils/stream.ts` 3115). Inherited base-red, nothing added by this batch — it is also why this PR's "Fast Quality Gates" check was red. |
||
|
Nguyen Thanh Dat
|
53e3e23c13 |
fix(api): stop DISABLE_SQLITE_AUTO_BACKUP from turning off Redis rate limiting (#13329)
A backup flag was being used as a proxy for test mode, so `DISABLE_SQLITE_AUTO_BACKUP` also disabled Redis rate limiting — two unrelated concerns riding one variable. Probe on your head: 3/3 + 13/13 pass across the new test and the existing rate-limiter suite. Thanks, @datrixlab — catching that the existing rate-limiter tests still pass is what shows this untangled the two without changing the intended behavior of either. **Batch validation** — boarded with the other 10 PRs of your batch into one worktree cut from `release/v3.8.51`; every PR verified as an ancestor of the combined HEAD before validating. - Focused tests across all 11 PRs: **104/104 pass** on the combined tree. - Gates on the combined tree: `check-changelog-integrity` PASS, `check-complexity` PASS, `check-cognitive-complexity` PASS, `typecheck:core` PASS, `check:open-sse-typecheck` PASS. - `check-file-size` is red, but reproduces with byte-identical line counts on the pure `release/v3.8.51` tip (`open-sse/handlers/imageGeneration.ts` 3304, `open-sse/services/combo/roundRobinCombo.ts` 1221, `open-sse/utils/stream.ts` 3115). Inherited base-red, nothing added by this batch — it is also why this PR's "Fast Quality Gates" check was red. |