The Next.js Data Cache Error That Broke My Production App (And How I Fixed It)

A real bug from building Flacron Gamezone — a live football platform built on Next.js 14 App Router.

There's a particular kind of bug that only shows up in production. Not because your environment variables are wrong or your build config is off — but because the framework is doing exactly what it was designed to do, and that design doesn't match what you assumed.

This is the story of one of those bugs.

The Setup

Flacron Gamezone is a live football match discovery platform. The matches page lists upcoming and live games, paginated, with filters. Simple enough on the surface.

The data fetching was originally done server-side. A server component would call a helper function — apiGet() — which internally called fetch() and returned the parsed JSON. The page rendered on the server, data included, and everything worked locally.

Then we deployed.

The Error

In production, the matches page started throwing a cryptic error after the first load:

Error: Dynamic server usage: Page couldn't be rendered statically because it used `headers`

Or sometimes, depending on the Next.js version and the exact request path:

Error: Cannot read properties of undefined (reading 'data')

What made it worse: it was intermittent. Refresh the page five times and it worked four of them. That kind of flakiness is the hardest to debug because it makes you doubt whether the bug is even real.

What Was Actually Happening

Next.js App Router has a built-in data cache. When you call fetch() inside a server component, Next.js caches that response by default — across requests, not just within a single render.

The problem: our apiGet() helper wasn't setting cache: "no-store". So Next.js was caching the first response and serving that cached data on subsequent requests — even when the underlying data had changed.

For a football platform showing live scores, stale cached data isn't just a bug. It's the whole product being wrong.

But there was a second problem layered on top. The server component was trying to read paginated data based on URL search params (?page=2, ?status=live). In some rendering paths, Next.js couldn't statically analyze those dynamic dependencies cleanly — especially when combined with the caching behavior. That's where the Dynamic server usage error was coming from.

The two issues were compounding each other.

What I Tried First (That Didn't Work)

The first instinct was to just add cache: "no-store" to the fetch calls inside apiGet().

const res = await fetch(url, { cache: "no-store" });

That fixed the stale data problem. But the intermittent render error on dynamic params persisted. The server component was still trying to read searchParams in a way that conflicted with how App Router handles static vs dynamic rendering.

I also tried wrapping the page in export const dynamic = "force-dynamic". That made the error go away — but it also meant the entire page was fully server-rendered on every request with no caching benefit at all. For a page with pagination and filters, that felt like giving up rather than solving the problem.

The Actual Fix: Move Pagination to the Client

The real solution was rethinking where the data fetching happened.

The matches listing didn't need to be a server-rendered data fetch at all. The page shell — the layout, the filters UI, the heading — could render on the server. But the paginated match data should be fetched client-side, on demand, triggered by the user's current page and filter state.

Here's what the refactored approach looked like:

Before (server component fetching paginated data):

// app/matches/page.tsx
export default async function MatchesPage({
  searchParams,
}: {
  searchParams: { page?: string; status?: string };
}) {
  const page = Number(searchParams.page) || 1;
  const data = await apiGet(`/matches?page=${page}&status=${searchParams.status}`);

  return <MatchList matches={data.matches} total={data.total} />;
}

After (client component fetching on state change):

// app/matches/page.tsx — server component, renders the shell
export default function MatchesPage() {
  return <MatchesClient />;
}

// components/MatchesClient.tsx — "use client"
"use client";

import { useState, useEffect } from "react";

export default function MatchesClient() {
  const [page, setPage] = useState(1);
  const [status, setStatus] = useState("all");
  const [matches, setMatches] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchMatches = async () => {
      setLoading(true);
      const res = await fetch(
        `${process.env.NEXT_PUBLIC_API_BASE}/matches?page=${page}&status=${status}`,
        { cache: "no-store" }
      );
      const data = await res.json();
      setMatches(data.matches);
      setLoading(false);
    };

    fetchMatches();
  }, [page, status]);

  return (
    // render matches, pagination controls, filter buttons
  );
}

The key changes:

1. The server component becomes a thin shell that renders the client component. No data fetching, no dynamic param reading.
2. The client component owns the pagination and filter state via useState.
3. useEffect re-fetches whenever page or status changes — cleanly, predictably, with no caching issues because we control the fetch directly.
4. cache: "no-store" is explicit on every fetch. No surprises.

Why This Is Actually the Right Model for This Feature

It's tempting to feel like moving data fetching to the client is "giving up" on the server-side rendering benefits of App Router. But that framing misses the point.

Server components are excellent for data that's:

• Known at request time
• Not dependent on user interaction state
• Appropriate to cache (even briefly)

Paginated, filterable, user-driven listings are none of those things. The user's current page and filter selection is the state. It changes constantly. Trying to drive that from the server via URL params creates exactly the kind of rendering ambiguity that caused this bug.

Client-side fetching for interactive, stateful UI isn't a fallback. It's the correct tool.

The Broader Lesson

Next.js App Router is powerful, but it has opinions. It will cache your fetch calls unless you tell it not to. It will try to statically optimize your pages unless you tell it they're dynamic. When those defaults conflict with what your feature actually needs, you don't fight the framework — you understand what it's trying to do and work with the model it's designed around.

In this case, the model is clear: server components for stable, cacheable data. Client components for interactive, user-driven state. The bug was the framework telling me I'd put the logic in the wrong place.

Summary

If you're building on Next.js 14 App Router and hitting intermittent cache-related errors on pages with dynamic params — check where your fetch calls live and who owns the state. The answer is usually in the split between server and client, not in your network or your API.

Ahmed Ali is a Full-Stack Developer based in Pakistan, building production-ready web apps with Next.js, Node.js, PostgreSQL, and TypeScript. Flacron Gamezone is live at flacrongamezone.com. Reach me at syedahmedali.com.