fix(bridge): prevent catch-all redirect from swallowing background-fn kickoff
Two-part hotfix for PR #205. Symptom: re-index UI showed "Large re-index started in the background" but no work ran, the lock sat for 16 min, and `setLastIndexedAt` never fired so the "Last indexed" UI line stayed empty.
Root cause: `deploy/bridge/netlify.toml`'s catch-all `[[redirects]] from = "/*" force = true` was rewriting `/.netlify/functions/bridge-index-background` to `/.netlify/functions/bridge/.netlify/functions/bridge-index-background`, which the regular bridge function 404'd on. `await fetch(...)` resolved successfully on the 404 (fetch only throws on network errors), so the sync handler returned `202 status:"background"` to the browser while no work ran.
Two-line fix: 1. `deploy/bridge/netlify.toml` — add explicit `/.netlify/functions/*` passthrough redirect placed BEFORE the catch-all. Netlify is first-match-wins, so this short-circuits the catch-all for direct function URLs (Netlify's normal `/.netlify/...` exemption is bypassed when `force = true` is set, verified empirically). 2. `hub/bridge/server.mjs` — `kickOffBackgroundIndex` now reads the response body and asserts HTTP 202 via the new pure helper `lib/bridge-index-kickoff-response.mjs`. Defense in depth: any future misconfiguration that produces a non-202 will throw, the existing catch handler will release the lock, and the UI will surface a 502 with the actual reason instead of falsely succeeding.
Tests: +9 unit tests for the validator + 2 contract tests for the netlify.toml ordering and bridge wiring. Full suite: 1893/1892/0/1 (was 1881 baseline + 11 new). No lint errors. No secrets in diff.
Sync re-index path is unchanged and was never affected. Existing stale locks (acquired during the buggy window) self-expire after 16 min via `acquireJobLock`'s overwrite-on-stale logic.
0 comments
muse hub commit comment sha256:17db4f43b470270c702eb15acad24a8bb3454c7948b8024751da779d44484760 --body "your comment"
No comments yet. Be the first to start the discussion.