Current state
The Next.js build fetches live data from Notion, TMDB, and iTunes at build time. If any of these API calls throws — due to a service outage, a rate limit, an expired token, or a network blip — the entire build fails and no deployment occurs. Visitors see a stale deployment or a total outage depending on the hosting behaviour, with no page-level degradation. There is no retry logic, no cache of a previous successful response, and no partial-render path that would let unaffected pages build successfully.
Ideal state
- A failure in one data source (e.g. TMDB being unavailable) does not prevent pages that depend on other sources from building and deploying.
- Pages that cannot render without fresh data fall back to the most recent cached API response, or display a "content temporarily unavailable" placeholder rather than causing a build failure.
- The build log clearly identifies which data source failed and why, so the cause can be diagnosed without inspecting raw error output.
Out of scope
- Real-time data freshness — build-time caching of the previous successful response is sufficient.
- Changes to the hosting or deployment pipeline.
- Handling failures in the static asset pipeline (images, fonts).
Starting points
app/blog/page.test.tsx — tests that exercise API failure paths and reveal the current all-or-nothing behaviourio/notion/ — Notion client used across multiple page typesapp/likes/page.tsx — page that depends on Notion, TMDB, and iTunes simultaneously
QA plan
- Set an invalid
NOTION_TOKEN in the environment, run next build — expect the build to complete; the blog page should render a "content temporarily unavailable" state or fall back to cached data, not fail the build.
- With Notion blocked, visit
/blog/ in the deployed output — expect readable content or a graceful placeholder, not a 500 or blank page.
- Restore a valid
NOTION_TOKEN, run next build — expect a normal build with fresh content and no placeholder states (no regression).
- Block TMDB only and run
next build — expect the likes page to degrade gracefully while the blog page builds normally.
Done when
A single external API being unavailable during the build does not prevent the site from building; affected pages degrade gracefully rather than blocking the full deployment.
Current state
The Next.js build fetches live data from Notion, TMDB, and iTunes at build time. If any of these API calls throws — due to a service outage, a rate limit, an expired token, or a network blip — the entire build fails and no deployment occurs. Visitors see a stale deployment or a total outage depending on the hosting behaviour, with no page-level degradation. There is no retry logic, no cache of a previous successful response, and no partial-render path that would let unaffected pages build successfully.
Ideal state
Out of scope
Starting points
app/blog/page.test.tsx— tests that exercise API failure paths and reveal the current all-or-nothing behaviourio/notion/— Notion client used across multiple page typesapp/likes/page.tsx— page that depends on Notion, TMDB, and iTunes simultaneouslyQA plan
NOTION_TOKENin the environment, runnext build— expect the build to complete; the blog page should render a "content temporarily unavailable" state or fall back to cached data, not fail the build./blog/in the deployed output — expect readable content or a graceful placeholder, not a 500 or blank page.NOTION_TOKEN, runnext build— expect a normal build with fresh content and no placeholder states (no regression).next build— expect the likes page to degrade gracefully while the blog page builds normally.Done when
A single external API being unavailable during the build does not prevent the site from building; affected pages degrade gracefully rather than blocking the full deployment.