{"slug": "a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy", "title": "A CORS Mismatch That Broke DocMind AI on a Fresh Netlify Deploy", "summary": "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.", "body_md": "*This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.*\n\n[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.\n\nThe backend already had CORS configured correctly in principle — `CORSMiddleware`\n\nwas in place, scoped to a specific origin rather than a wildcard, with `allow_credentials=False`\n\nand an explicit method/header allowlist. That part was never the problem.\n\nThe actual bug was a domain mismatch. The frontend had been redeployed to a new Netlify site, `docmindai-chatbot.netlify.app`\n\n— note the hyphen — while the backend's `allow_origins`\n\nlist still only contained the old domain, `docmindaichatbot.netlify.app`\n\n, 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.\n\nCommit: [291e6d8 — Update CORS to allow new Netlify domain](https://github.com/uroojbuilds/Docmind-Ai/commit/291e6d85541181e9ae388b8d2285a766089e93c5)\n\nBefore:\n\n```\nallow_origins=[\"https://docmindaichatbot.netlify.app\"],\n```\n\nAfter:\n\n```\nallow_origins=[\"https://docmindai-chatbot.netlify.app\", \"https://docmindaichatbot.netlify.app\"],\n```\n\nFull block, unchanged parts included for context:\n\n```\napp.add_middleware(\n    CORSMiddleware,\n    allow_origins=[\"https://docmindai-chatbot.netlify.app\", \"https://docmindaichatbot.netlify.app\"],\n    allow_credentials=False,\n    allow_methods=[\"GET\", \"POST\", \"OPTIONS\"],\n    allow_headers=[\"Content-Type\", \"Accept\"],\n)\n```\n\nRepo: [uroojbuilds/Docmind-Ai](https://github.com/uroojbuilds/Docmind-Ai)\n\nLive demo: [docmindai-chatbot.netlify.app](https://docmindai-chatbot.netlify.app/)\n\nThe 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`\n\nheader, 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`\n\nor 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.\n\nRather than loosen the config to `allow_origins=[\"*\"]`\n\n— 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`\n\nand a tight `allow_methods`\n\n/`allow_headers`\n\nlist, 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.\n\nThe 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`\n\nis one of the first things I verify before calling it done.", "url": "https://wpnews.pro/news/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy", "canonical_source": "https://dev.to/codewithurooj/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy-published-79c", "published_at": "2026-07-23 10:35:52+00:00", "updated_at": "2026-07-23 11:00:05.321069+00:00", "lang": "en", "topics": ["developer-tools", "ai-products"], "entities": ["DocMind AI", "Netlify", "FastAPI", "Groq", "Pinecone", "HuggingFace", "uroojbuilds"], "alternates": {"html": "https://wpnews.pro/news/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy", "markdown": "https://wpnews.pro/news/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy.md", "text": "https://wpnews.pro/news/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy.txt", "jsonld": "https://wpnews.pro/news/a-cors-mismatch-that-broke-docmind-ai-on-a-fresh-netlify-deploy.jsonld"}}