fix: thread fallback model through params instead of setChatModel

[dylanneve1]

Summary

• Critical (3 sites): setChatModel-based fallback retry pattern is a silent no-op. Commit fix: pass resolved chat model into backends #248 introduced params.model which all backends resolve before chatSettings.model, so the transient setChatModel flip was never observed. Fixed in src/backend/shared/handle-retry.ts, src/backend/codex/handler.ts, and src/backend/openai-agents/handler.ts by spreading { ...params, model: fallbackModelId } into the recursive call.
• Medium: mapListModels in adapter.ts returned the pre-filter total from the legacy backend after applying selectableOnly and query client-side filters, violating the ModelList interface contract (total = count after filter). Fixed to return mapped.length.
• Low: Dead code in legacy-bridge.ts reduceEventsToResult — ...(saw ? {} : {}) spreads an empty object on both branches. Removed.
• Test: Updated shared-handle-retry.test.ts to assert on paramsSeenInRecursion.model (new mechanism) rather than getChatSettings().model (old mechanism that no longer fires).

Root cause

Commit #248 ("fix: pass resolved chat model into backends") wired params.model into every backend.query() call from the dispatcher. Every backend resolves model as params.model ?? chatSettings.model, so any setChatModel call made immediately before recurseWithRetried(params) / handleMessage(params, true) is masked — the unchanged params.model wins. The fallback model was never actually used.

Test plan

• npm test — shared-handle-retry.test.ts fallback_model suite verifies fallback model is received in the recursive call via paramsSeenInRecursion.model
• Manual: trigger a rate-limit / overload / network error on a chat with a model that has a configured fallback; confirm the retry uses the fallback model
• adapter.ts — confirm a filtered listModels call returns total === models.length

https://claude.ai/code/session_01Pe2jJNJoMiDUSffdVqiX6P

---

Generated by Claude Code

[claudiusthebot]

Approved. All three bugs are real and the fixes are correct.

---

CI fix pushed (commit bd248ab)

The 4 Tests matrix jobs were failing due to a strictFunctionTypes violation in the updated test. The fallback_model mock was typed as (p: typeof stubParams & { model?: string }) which has isGroup: boolean (required). QueryParams has isGroup?: boolean (optional). TypeScript's contravariance rule means a function accepting the narrow type isn't assignable to one accepting QueryParams (a QueryParams value where isGroup is undefined can't satisfy the required boolean). Fixed by typing the mock parameter as QueryParams and importing the type — the assertion paramsSeenInRecursion.model === "fallback" still works since QueryParams.model?: string.

---

Overlap with existing open PRs

This PR partially overlaps with three others that are waiting to merge:

Fix in this PR	Also in
setChatModel model-wipe (3 files)	PR #260 Bug 1, PR #257 Bugs 1+2
Dead saw code in legacy-bridge.ts	PR #263 Bug 3
mapListModels wrong total after filter	New — not in any other PR

The mapListModels fix is unique value here. The other two are duplicated.

Suggested merge order: merge this PR first (it's the most focused fix for the setChatModel issue, and has the mapListModels new fix), then:

• Rebase PR #260: drop Bug 1 (now covered), keep Bugs 2–5
• Rebase PR #263: drop Bug 3 (dead saw variable now covered), keep Bugs 1–2

PR #257 is a subset of #260 — still worth keeping as a narrower, independent set once #265 lands.

CI should go green with the QueryParams type fix commit. — hb #539

[claudiusthebot]

Second CI fix — commit 54c5600

My bd248ab fix resolved the strictFunctionTypes violation in shared-handle-retry.test.ts, but the Tests jobs were still failing due to a second issue I missed:

Root cause: agent-runtime-adapter.test.ts line 402 was asserting expect(onlySelectable.total).toBe(3) — the pre-filter count. But PR #265 Bug 2 changes mapListModels to return mapped.length (post-filter count), so total is now 2 when selectableOnly: true filters "b" out of the 3-model list. The test was encoding the old (wrong) behaviour as the expected value.

Fix: Updated the assertion to toBe(2) and added a matching assertion for the query filter case.

Summary of all CI fixes on this PR:

• bd248ab — strictFunctionTypes violation: mock param typed as typeof stubParams & { model?: string } → QueryParams
• 54c5600 — stale test assertion: total.toBe(3) → total.toBe(2) to match post-filter semantics

Both fixes are test-only. Source changes are unchanged.