fix(compression): apply compression combo assignments to routing combos

[ekinnee]

Summary

Compression combo assignments (output mode, pipeline overrides) are correctly saved in the database but never applied to routing combos like codex, free-only, or-free.

Root Cause

The compression combo assignment lookup in open-sse/handlers/chatCore.ts was gated behind if (isCombo && comboName). Routing combos use provider-prefixed model strings (e.g. codex/gpt-5.5) and go through handleSingleModelChat, which passes comboName: null, isCombo: false — so the gate always blocked the lookup.

Additionally, even when the gate was passed, the lookup passed human-readable combo names (like "codex") to getCompressionComboForRoutingCombo(), but the DB stores assignments keyed by routing combo UUID. The name-based lookup always returned null.

Fix

Three changes across three files:

1. open-sse/handlers/chatCore.ts — Added routingComboId parameter. Changed the gate from if (isCombo && comboName) to if ((isCombo && comboName) || routingComboId). Added routingComboId to the lookup key array so the DB query uses the UUID directly.

2. src/sse/handlers/chat.ts — In handleChat(), when no explicit combo is matched, resolve the routing combo UUID from the model string's provider prefix via getComboByName(). Thread the UUID through handleSingleModelChat → executeChatWithBreaker → handleChatCore.

3. src/sse/handlers/chatHelpers.ts — Added routingComboId parameter to executeChatWithBreaker() and threaded it to the handleChatCore call.

Testing

• Typecheck: ✅ pnpm typecheck:core passes
• Unit tests: ✅ 1283/1283 passing (compression tests included)
• No existing behavior changed for named combo requests (the isCombo && comboName path still works identically)

Related

• Fixes fix(backend): compression combo output mode and pipeline overrides not applied to routing combos #7771
• DB assignments confirmed stored correctly with routing combo UUIDs

[gemini-code-assist]

Code Review

This pull request introduces numerous features, bug fixes, and maintenance updates, including a new Mergify merge queue configuration, a CLI fast-path for version queries, and an improved native binary compatibility check for better-sqlite3. However, a critical issue was identified in bin/cli/runtime/nativeDeps.mjs where spawnSync is used within the new probeNativeBinaryLoadable function but is not imported, which will cause a silent ReferenceError and force unnecessary binary rebuilds on every startup.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The function probeNativeBinaryLoadable uses spawnSync to probe the native binary in a subprocess. However, spawnSync is not imported in this file (bin/cli/runtime/nativeDeps.mjs). This will cause a ReferenceError when spawnSync is called, which is caught by the try-catch block and silently returns false. As a result, isBetterSqliteBinaryValid() will always return false, triggering an unnecessary rebuild of the better-sqlite3 binary on every startup.\n\nPlease add the missing import at the top of bin/cli/runtime/nativeDeps.mjs:\njavascript\nimport { spawnSync } from \"node:child_process\";\n

[diegosouzapw]

Thanks for the clear root-cause writeup — this matches the code exactly: the compression-combo lookup in chatCore.ts really is gated behind isCombo && comboName, which routing combos (codex/free-only/or-free) never set, and getCompressionComboForRoutingCombo() really is keyed by UUID while the old code only ever passed names. Good catch on #7771, and the fix (threading an optional routingComboId through handleSingleModelChat → executeChatWithBreaker → handleChatCore) is the right minimal shape — it's backward compatible with the existing explicit-combo path.

Two things before this can land:

1. Tests — this PR changes production routing logic in open-sse/handlers/chatCore.ts, src/sse/handlers/chat.ts, and src/sse/handlers/chatHelpers.ts with no test coverage. Per our contribution rules, a bug fix needs a regression test that reproduces the bug and proves the fix (e.g. extending tests/integration/chatcore-compression-integration.test.ts with a routing-combo case that has a compression combo assigned via routingComboId and asserting the output mode/pipeline actually applies). Happy to help draft this if useful.

2. Branch base — your branch is currently ~600 commits behind current main and targets main instead of our active integration branch release/v3.8.49. Merging it as opened would revert a large amount of code that has shipped since your fork point. We're going to cherry-pick just your fix commit (431e48df4) onto release/v3.8.49 with your authorship preserved, add the missing test, and get it merged that way — your diagnosis and fix are exactly right, we just need to land it on top of current release/v3.8.49 with a test attached. Will follow up here once that's ready for your review.

[ekinnee]

Thanks for the clear root-cause writeup — this matches the code exactly: the compression-combo lookup in chatCore.ts really is gated behind isCombo && comboName, which routing combos (codex/free-only/or-free) never set, and getCompressionComboForRoutingCombo() really is keyed by UUID while the old code only ever passed names. Good catch on #7771, and the fix (threading an optional routingComboId through handleSingleModelChat → executeChatWithBreaker → handleChatCore) is the right minimal shape — it's backward compatible with the existing explicit-combo path.

Two things before this can land:

1. **Tests** — this PR changes production routing logic in `open-sse/handlers/chatCore.ts`, `src/sse/handlers/chat.ts`, and `src/sse/handlers/chatHelpers.ts` with no test coverage. Per our contribution rules, a bug fix needs a regression test that reproduces the bug and proves the fix (e.g. extending `tests/integration/chatcore-compression-integration.test.ts` with a routing-combo case that has a compression combo assigned via `routingComboId` and asserting the output mode/pipeline actually applies). Happy to help draft this if useful.

2. **Branch base** — your branch is currently ~600 commits behind current `main` and targets `main` instead of our active integration branch `release/v3.8.49`. Merging it as opened would revert a large amount of code that has shipped since your fork point. We're going to cherry-pick just your fix commit (`431e48df4`) onto `release/v3.8.49` with your authorship preserved, add the missing test, and get it merged that way — your diagnosis and fix are exactly right, we just need to land it on top of current `release/v3.8.49` with a test attached. Will follow up here once that's ready for your review.

Whatever is easiest for you, I can do the work if you'd like.

[diegosouzapw]

Validated in local merge-train on 192.168.0.113 @ 4c7058069292fa601621cb616d233be21e096e06 (FAST gates green: static + changed tests + vitest; today's full-suite parity ran in trains 4+5)