Two files both claimed migration version 135:
135_connection_runtime_state.sql (#9449, landed 2026-08-07) and
135_migrate_model_capability_max_token.sql (#8908, landed 2026-08-05).
#9449 branched before #8908 merged and never got renumbered before
landing on release/v3.8.50.
This is not cosmetic: getMigrationFiles() throws "Migration version
collision detected" the moment ANY code path first touches the
database (getDbInstance() -> runMigrations()), which means a
completely fresh install/deploy from this branch cannot even boot —
confirmed live against a freshly built container while testing
unrelated live-verification tooling.
Renumbered the later-landing file to 140 (the next free slot) and
added the matching isSchemaAlreadyApplied("140") retroactive guard in
migrationRunner.ts, so a DB that already ran this migration under the
old 135 number isn't treated as needing a fresh application. This
matches the established pattern already used for the prior 135/136 ->
137/138 renumber in the same file (also caused by the same recurring
branch-before-merge numbering race).
Test plan:
- TDD: new tests/unit/migration-135-numbering-collision.test.ts (2/2)
— spins up a hermetic fresh DB and confirms getDbInstance() applies
every real on-disk migration without throwing, plus confirms both
formerly-135 migrations' effects are present. Confirmed failing
(reproducing the exact live crash) with the pre-fix colliding
filenames restored, passing after the rename.
- npm run typecheck:core — clean
- npm run lint — clean
- npm run check:file-size — clean (migrationRunner.ts rebaselined
1084->1094 for the new guard case)
- Full migration-runner + migration-numbering test suites (64 tests
across 6 files) — all pass, no regressions
The specialty model catalog loops (image, rerank, audio, moderation, video,
music) in catalog.ts reduced OpenRouter model IDs to only the final path
segment via .split("/").pop() before calling getModelIsHidden(), so stored
hidden flags with full provider-relative paths (e.g. openrouter+google/chirp-3)
were never matched.
Fix: introduce a shared getSpecialtyModelRelativeId helper that strips only
the provider prefix (like the embedding loop already did), and apply it to
all 6 affected specialty loops. Also add a hidden-model guard to the live
OpenRouter catalog path that had no such check at all.
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(web-search): bind each search provider attempt to its connection proxy (#9201)
The search path resolved credentials but never resolved the connection
proxy, so the upstream fetch always egressed directly. The connection-test
path already used the proxy correctly, proving the gap was in the
data-plane transport binding.
- Resolve the connection proxy before each upstream attempt using the
existing resolveProxyForConnection(connectionId, apiKeyId, providerId)
precedence chain, then wrap the fetch in runWithProxyContext so the
patched globalThis.fetch routes through the configured proxy.
- Resolve and bind the alternate connection proxy independently during
failover, so the primary account's context never leaks into the fallback.
- Carry connectionId and apiKeyId through SearchHandlerOptions into the
route and executeWebSearch callers.
- Add connectionId to all saveCallLog entries in tryProvider, so the
regular call log identifies the account.
- Emit a sanitized logProxyEvent per real upstream search attempt with
provider, connection ID, proxy level, status, duration, and target
origin/path (no query, API key, or proxy credentials).
- Cover both POST /v1/search and executeWebSearch() consumers (MCP,
internal, skills) since both bypassed the same proxy binding.
* fix(sse): extract search proxy binding into leaf module to fit file-size cap
Move the per-attempt proxy resolution, proxied fetch, sanitized proxy-event
emission, and response handling for web search providers out of
open-sse/handlers/search.ts into a new open-sse/handlers/search/searchProxy.ts,
so the provider-dispatch chokepoint (tryProvider) stays a thin wiring call and
search.ts fits back under the frozen file-size cap (1536 lines).
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
