A CORS Mismatch That Broke DocMind AI on a Fresh Netlify Deploy

A developer fixed a CORS mismatch that broke DocMind AI, a RAG-based document chatbot, after a Netlify redeploy. The backend's allow_origins list still contained the old domain without a hyphen, blocking requests from the new deployment. The fix added the missing domain to the allowlist.

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. DocMind AI https://docmindaichatbot.netlify.app is a RAG-based document chatbot — you upload documents and ask questions about them, and it retrieves relevant context and generates grounded answers. The stack: FastAPI backend, Groq LLaMA 3.3 for generation, Pinecone for vector storage, HuggingFace embeddings, and a Netlify-hosted frontend, with voice input/output built on top. The backend already had CORS configured correctly in principle — CORSMiddleware was in place, scoped to a specific origin rather than a wildcard, with allow credentials=False and an explicit method/header allowlist. That part was never the problem. The actual bug was a domain mismatch. The frontend had been redeployed to a new Netlify site, docmindai-chatbot.netlify.app — note the hyphen — while the backend's allow origins list still only contained the old domain, docmindaichatbot.netlify.app , without the hyphen. Two names that look almost identical at a glance, but the browser treats them as completely different origins. Every request from the new deployment was blocked before it reached the API, while the old domain kept working fine — which made it easy to miss at first, since "the app works" and "the app works from the URL I'm actually testing" turned out to be different claims. Commit: 291e6d8 — Update CORS to allow new Netlify domain https://github.com/uroojbuilds/Docmind-Ai/commit/291e6d85541181e9ae388b8d2285a766089e93c5 Before: allow origins= "https://docmindaichatbot.netlify.app" , After: allow origins= "https://docmindai-chatbot.netlify.app", "https://docmindaichatbot.netlify.app" , Full block, unchanged parts included for context: app.add middleware CORSMiddleware, allow origins= "https://docmindai-chatbot.netlify.app", "https://docmindaichatbot.netlify.app" , allow credentials=False, allow methods= "GET", "POST", "OPTIONS" , allow headers= "Content-Type", "Accept" , Repo: uroojbuilds/Docmind-Ai https://github.com/uroojbuilds/Docmind-Ai Live demo: docmindai-chatbot.netlify.app https://docmindai-chatbot.netlify.app/ The fix itself is a one-line addition, but the useful part was figuring out it was a CORS problem specifically, and not a broken deploy. The browser's network tab showed requests failing with no Access-Control-Allow-Origin header, while the backend logs showed nothing at all for those requests — which is the classic CORS signature: the browser blocks the request before your server code ever runs, so there's nothing to catch in a try/except or print statement. If the API were actually down, curling it directly would have failed too; instead, curl worked fine and only the browser call from the new Netlify URL failed, which pointed straight at an origin allowlist problem. Rather than loosen the config to allow origins= " " — which would have made the symptom disappear immediately — I kept the existing narrow, explicit list and just added the missing domain. The backend already had allow credentials=False and a tight allow methods / allow headers list, which is good practice for a public API even without cookies in play, and a one-off deploy mismatch isn't a reason to give that up for convenience. The lesson that's stuck with me: Netlify doesn't guarantee it'll reuse the exact site name you expect on every deploy, and a CORS allowlist has to track the actual deployed origin, not the one you assumed you'd get. Now when I redeploy the frontend, checking the live URL against allow origins is one of the first things I verify before calling it done.