This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.
DocMind AI 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
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
Live demo: 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.