How a Single CDN Addition Broke Our App, and What It Taught Us About the Invisible Contract Between Infrastructure and Code
<hr>
<blockquote>
Your code doesn’t run in a vacuum. It runs on infrastructure. And infrastructure has opinions.
</blockquote>
<hr>
<h2>The Setup That Should Have Been Identical</h2>
We had a production-grade AI chatbot platform a Next.js dashboard backed by a FastAPI server. Three AWS deployments, same codebase, same Docker image, same CI/CD pipeline.
Server A and Server B worked flawlessly. Users could open a chat, send a message, and get an AI response. Simple.
Server C did something different. When a user sent the very first message in a new chat:
<ul>
<li>The screen blinked</li>
<li>The message vanished</li>
<li>No response appeared</li>
<li>The network tab showed a cancelled request</li>
</ul>
But here’s the maddening part if the user refreshed the page, the chat appeared in the sidebar. The backend had received and processed the message. The data was there. The UI just… self-destructed before it could render.
Same code. Same image. Three servers. One broken.
<hr>
<h2>The Debugging Spiral</h2>
We started where any engineer would the code.
We checked the API layer. Intact. We checked the Redux store. Correct. We checked the authentication interceptors. No rogue logouts. We added debug logging to every layer component mount/unmount, axios interceptors, Redux dispatches.
The logs told us something strange: the entire React component tree was unmounting and remounting during the first message send. Not a re-render. A full destruction and reconstruction. The Redux store was being wiped clean mid-API-call.
This wasn’t a React bug. This was a navigation event.
<hr>
<h2>The Invisible Culprit</h2>
Here’s the code that worked perfectly on two servers and catastrophically failed on the third:
<pre><code>// ChatBlank.tsx The &quot;new chat&quot; screen
const handleSend = async (text: string) =&gt; {
 // 1. Create optimistic thread in Redux
 dispatch(addThread(optimisticThread));
 dispatch(setCurrentThread(tempThreadId));

 // 2. Navigate to the thread view
 router.replace(`/dashboard/chat?threadKey=${tempThreadId}`);

 // 3. Fire the API call
 const response = await chatApi.sendMessage({ question: text, ... });

 // 4. Update with real data
 dispatch(replaceThreadId({ oldId: tempThreadId, newThread: response }));
};
</code></pre>
On the surface, this is textbook optimistic UI. Create a temporary thread, navigate to it, fire the API, swap in real data when it arrives. And on Servers A and B, it worked exactly like that.
Server C had one infrastructure difference: CloudFront sat in front of Nginx.
<pre><code>Server A: Browser → Nginx → Next.js ✅
Server B: Browser → Nginx → Next.js ✅
Server C: Browser → CloudFront → Nginx → Next.js 💥
</code></pre>
<hr>
<h2>The Chain Reaction</h2>
Here’s what <code>router.replace()</code> actually does under the hood in Next.js App Router (v14+):
<ol>
<li>It sends an HTTP request to the server with special headers: <code>RSC: 1</code>, <code>Next-Router-State-Tree</code>, <code>Next-Url</code></li>
<li>The server responds with a lightweight RSC payload (<code>text/x-component</code>) not full HTML</li>
<li>React reconciles the diff and updates the DOM in-place</li>
</ol>
This is the React Server Components flight protocol. It’s elegant and fast when those headers reach the server intact.
CloudFront’s default Origin Request Policy (<code>Managed-HostHeaderOnly</code>) forwards exactly one header to the origin: <code>Host</code>. Every other header including <code>RSC: 1</code> gets silently stripped.
So when <code>router.replace()</code> fired on Server C:
<ol>
<li>Browser sends: <code>GET /dashboard/chat?threadKey=abc</code> with <code>RSC: 1</code></li>
<li>CloudFront strips <code>RSC: 1</code>, forwards a plain GET</li>
<li>Next.js sees a normal page request, responds with full HTML (<code>text/html</code>)</li>
<li>The browser receives HTML where it expected an RSC payload</li>
<li>Next.js client-side router falls back to a hard navigation full page reload</li>
<li>The Redux store is destroyed</li>
<li>The in-flight <code>sendMessage</code> API call is cancelled</li>
<li>The page remounts with a blank slate</li>
</ol>
The message reached the backend (it was already in-flight before the reload), but the response had nowhere to land. The component that dispatched it no longer existed.
<hr>
<h2>The Real Lesson: Infrastructure Is a Runtime Dependency</h2>
The fix wasn’t a one-line change. It required rethinking the assumption that was baked into the code:
<blockquote>
“Client-side navigation is always a lightweight, in-place update.”
</blockquote>
That assumption holds when your infrastructure is transparent to the framework’s protocol. The moment a CDN, proxy, or WAF modifies headers, the contract breaks and it breaks silently. No error. No warning. Just a fallback behavior that looks like a bug in your code.
<h3>The Fix: Decouple Navigation from API Calls</h3>
We moved the API call out of the component lifecycle entirely, into a Redux thunk. And we replaced <code>router.replace()</code> with <code>window.history.replaceState()</code> a browser-native API that updates the URL without triggering any server request.
<pre><code>// ChatBlank.tsx After fix
const handleSend = async (text: string) =&gt; {
 // 1. Create optimistic thread in Redux
 dispatch(addThread(optimisticThread));
 dispatch(setCurrentThread(tempThreadId));

 // 2. NO router.replace() let React re-render via Redux state change
 // 3. Fire API call at Redux level (survives component unmount)
 dispatch(sendFirstMessage({ text, model, user, tempThreadId }));
};
</code></pre>
<pre><code>// page.tsx View switches on Redux state, not URL
const activeThreadId = threadKey || currentThreadId;

if (composeMode || (!threadKey &amp;&amp; !currentThreadId)) {
 return &lt;ChatBlank /&gt;;
}
return &lt;ChatThread threadId={activeThreadId} /&gt;;
</code></pre>
<pre><code>// thunks/chat.ts API call + URL update happens at store level
const sendFirstMessage = (params) =&gt; async (dispatch) =&gt; {
 const response = await chatApi.sendMessage({ ... });

 dispatch(replaceThreadId({ oldId: tempThreadId, newThread }));
 dispatch(setCurrentThread(response.external_chat_id));

 // Update URL only after API completes, using browser API (no RSC fetch)
 window.history.replaceState(
 null, &#x27;&#x27;, 
 `/dashboard/chat?threadKey=${response.external_chat_id}`
 );
};
</code></pre>
What changed:
<ul>
<li>Before: <code>router.replace()</code> triggers RSC fetch</li>
</ul>
After: <code>window.history.replaceState()</code> – no server request
<ul>
<li>Before: API call lives in component (dies on unmount)</li>
</ul>
After: API call lives in Redux thunk (survives any re-render)
<ul>
<li>Before: View switches based on URL</li>
</ul>
After: View switches based on Redux state
<ul>
<li>Before: URL updates reactively via useEffect</li>
</ul>
After: URL updates imperatively after API success
<hr>
<h2>The Broader Takeaway</h2>
This bug didn’t appear in any test suite. It couldn’t it only manifested when a CDN sat between the browser and the server. The code was correct. The infrastructure was correctly configured for a traditional web app. But Next.js App Router isn’t a traditional web app. It has an implicit runtime protocol (RSC flight) that requires specific headers to pass through every layer of your infrastructure.
<h3>Three rules we now follow:</h3>
1. Treat your deployment topology as a code dependency.
If your code assumes <code>router.push()</code> does a lightweight RSC fetch, your infrastructure must forward RSC headers. Document this. Test this. Don’t discover it in production.
2. Never couple API calls to navigation events.
If a user action requires both “navigate somewhere” and “call an API,” those should be independent operations. Navigation can fail, be intercepted, or behave differently across environments. Your API call shouldn’t be collateral damage.
3. The same Docker image on different infrastructure is NOT the same deployment.
A CDN, a WAF, a reverse proxy each one is a participant in your application’s runtime behavior. “Works on my server” is the new “works on my machine.”
<hr>
<h2>The Humbling Part</h2>
The CloudFront distribution was added to Server C as a performance optimization faster static asset delivery, edge caching, DDoS protection. A routine infrastructure improvement. No one thought to check whether the CDN would interfere with a framework-level protocol that operates over HTTP headers.
It took a few hours of debugging across application code, Redux state, authentication flows, and network traces before we even looked at the infrastructure layer. The fix was ultimately ~40 lines of code. The diagnosis was the hard part.
Sometimes the most dangerous bugs aren’t in the code you write. They’re in the assumptions your code makes about the world it runs in.

This squad was established to be able to share anything about development. Post, Comment, and Upvote!

Dev World

A production Next.js app worked identically on two AWS deployments but broke on a third when CloudFront was added. The CDN stripped React Server Components headers (RSC: 1), causing router.replace() to trigger full page reloads instead of lightweight updates, destroying Redux state mid-API-call. The fix decoupled navigation from API calls by moving logic to Redux thunks and using window.history.replaceState() instead of Next.js router methods. The incident reveals how CDNs and proxies can silently break framework protocols that depend on specific HTTP headers passing through infrastructure layers.

When One Line of Code Works Everywhere - Except Behind CloudFront