Finish Cloudflare Workers deployment setup#101
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7e039f7aa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!origin) return '*'; | ||
| const allowedPatterns = [ | ||
| /^http:\/\/localhost:\d+$/, | ||
| /\.teraai\.chat$/, |
There was a problem hiding this comment.
The new worker CORS allowlist no longer permits the root production origin (https://teraai.chat): \.teraai\.chat$ matches subdomains like www.teraai.chat but not the apex domain. The previous Express config explicitly allowed process.env.WEB_URL, so this is a regression that will block browser calls from the main site once traffic uses this worker API (failed preflight / missing matching Access-Control-Allow-Origin).
Useful? React with 👍 / 👎.
| compatibility_date = "2025-01-01" | ||
| compatibility_flags = [ "nodejs_compat" ] |
There was a problem hiding this comment.
The backend Worker reads critical settings from process.env (for example Supabase and Mistral keys), but this config pins compatibility_date to 2025-01-01 while only enabling nodejs_compat. Cloudflare only auto-populates process.env by default for compatibility dates on/after 2025-04-01 (or when nodejs_compat_populate_process_env is explicitly enabled), so this deployment can start with empty env values and fail authentication/chat routes immediately.
Useful? React with 👍 / 👎.
| const nextConfig = { | ||
| reactStrictMode: false, | ||
| typescript: { | ||
| ignoreBuildErrors: true, |
There was a problem hiding this comment.
Setting typescript.ignoreBuildErrors to true allows production builds to succeed even when TypeScript reports errors. In this repo’s deploy workflow there is no separate type-check gate before deploy, so this change can silently ship broken code paths that would previously block release.
Useful? React with 👍 / 👎.
1 participant
What changed