A Missing force-dynamic Froze a Flag Flip Behind Static HTML

Conclusion

A public route with no dynamic API call is prerendered by Next.js at build time and cached long-term by the CDN through s-maxage. Changing a value in the database later never reaches the page unless force-dynamic is declared.

/login was designed to query the database for whether at least one school has shared login enabled and show the teacher login UI accordingly — but with no force-dynamic, the HTML from build time (zero enabled schools) was served frozen.

Symptom

A system admin set a school’s shared password and enabled teacher_login_enabled, and the teacher login UI still did not appear on /login. The database value updated correctly and the admin screens reflected it. Only the public /login stayed stale.

Cause

/login is a Server Component that queries the database on every request for schools with shared login enabled and switches on teacher mode accordingly. But with no force-dynamic, Next.js prerendered this public route at build time like any other static page. No school was enabled at build time, so HTML meaning “no teacher login” was frozen and given a s-maxage=31536000 (one year) long-term cache.

Checking the production response headers showed x-nextjs-prerender:1 and a cache HIT, identifying static prerendering as the cause.

The fix

Add export const dynamic = "force-dynamic" to /login, pinning it to dynamic rendering that queries the database on every request.

export const dynamic = "force-dynamic";

The actions that set and clear a school’s shared password (setSchoolTeacherPasswordAction / clearSchoolTeacherPasswordAction) also call revalidatePath("/login") to make the change appear immediately after enabling.

revalidatePath(`/ops/schools/${schoolId}/edit`);
revalidatePath(`/ops/schools/${schoolId}`);
revalidatePath("/login");

force-dynamic is the fix; revalidatePath is a second layer on top of it. Either one alone would let the symptom return if force-dynamic were accidentally removed later, or if teacher_login_enabled changed through some other path.

Why it went unnoticed

The teacher-login branch on /login reads correctly in review: “show the UI if any school is enabled”. In local development everything renders dynamically on every request, so the branch being frozen into a cache never reproduces.

The symptom only appears in production, through the CDN cache, where build-time HTML keeps being served for a long time. That logic is correct and that logic runs at the right time are two separate things to confirm.

For another Next.js caching story where the middleware allow-list was the cause, see auth middleware redirecting robots.txt to the login page.