feat(backend): wire interceptFetch into the chat pipeline (Phases 3-4 of #3384)

[thomasmaerz]

Summary

This tracks the deferred Phases 3-4 from #3384 / PR #6814: wiring interceptFetch into the SSE chat pipeline and adding the dashboard toggle.

What exists already

Phase 1-2 (shipped in #6814, release/v3.8.47):

• src/lib/db/interceptionRules.ts — DB CRUD for interception_rules (key_value namespace), with fields for both interceptSearch and interceptFetch
• resolveInterceptSearch(provider, model) — fully implemented
• prepareWebSearchFallbackBody() wired in chatCore.ts with the search override

The DB types already include: interceptFetch, fetchBackend, fetchProxyUrl at both provider and per-model level — so no schema changes are needed.

What's missing (Phases 3-4)

1. resolveInterceptFetch(provider, model) — analogous to resolveInterceptSearch, returning boolean | undefined with the same provider to model precedence.

2. Call site in the chat pipeline — when interceptFetch === true, route the provider-native web_fetch tool call through OmniRoute's /v1/web/fetch instead of letting it pass through to the provider. This mirrors how interceptSearch routes to /v1/search in webSearchFallback.ts.

3. Dashboard UI toggle — a per-model / per-provider toggle in the dashboard settings UI (the PR description explicitly deferred this).

Implementation guidance

• Follow the exact pattern of resolveInterceptSearch / webSearchFallback.ts — the search and fetch paths are structurally parallel.
• /v1/web/fetch already exists (src/app/api/v1/web/fetch/route.ts, backed by open-sse/handlers/webFetch.ts), so the interceptor just needs to route to it.

References

• Original feature request: [Feature] Intercept provider-native web search and web fetch tool calls through OmniRoute's own /v1/search and /v1/web/fetch #3384
• Merged PR (Phases 1-2): feat: per-model web-search interception rule (#3384) #6814
• DB module: src/lib/db/interceptionRules.ts
• Search interceptor (reference pattern): open-sse/services/webSearchFallback.ts
• Existing fetch endpoint: src/app/api/v1/web/fetch/route.ts

[diegosouzapw]

Confirmed — verified resolveInterceptFetch doesn't exist yet and the DB fields / fetch endpoint from Phases 1-2 are exactly as you described. This is a clean, low-risk follow-up mirroring the already-shipped interceptSearch pattern.

Status: ✅ Accepted — queued for implementation (high readiness, structurally identical to already-merged prior art)

Thanks for tracking the deferred phases so precisely!

[diegosouzapw]

🚧 PR opened for release/v3.8.49!

Your feature request has an implementation ready — PR #7736 is open and awaiting the maintainer's review.

What was done:

• interceptFetch is now wired into the chat pipeline plus a provider-level dashboard toggle (built fresh — it didn't exist even for the sibling interceptSearch). Gated behind an opt-in flag with a byte-identical-pipeline regression test when off
• Ships with new behavior tests (no existing test assertion was removed or weakened)

This will ship once the PR is merged and included in the upcoming v3.8.49 release. 🚀

[diegosouzapw]

✅ Partially shipped — PR #7736 is merged into release/v3.8.49.

What shipped:

• interceptFetch wired into the chat pipeline plus the provider-level dashboard toggle (built fresh — it did not exist even for the sibling interceptSearch), gated behind an opt-in flag

Kept open because this remains:

• Only the per-model UI row (provider-level is done; per-model overrides remain reachable via the API's models field) and exposing fetchBackend/fetchProxyUrl as UI controls

That's why the PR used Refs rather than Closes — the remaining scope is real work, not an oversight. Leaving this open to track it. 🙏