fix: guard React transition runtime APIs

[cursor]

Bug and impact

Several client components imported addTransitionType and ViewTransition directly from react, but the installed react@19.2.8 runtime exposes both as undefined. Rendering pages with <ViewTransition> or clicking navigation/filter/search controls that call addTransitionType(...) can crash high-traffic app surfaces such as global navigation, course search, notes search, and past-paper pages.

Root cause

The code relied on canary React view-transition APIs present in type definitions / Next docs, but not exported by the installed React runtime.

Fix

Added a shared react-transition compatibility helper that no-ops transition type registration and falls back to plain children when ViewTransition is unavailable, then routed all existing direct call/render sites through it.

Validation

• CI=true corepack pnpm exec tsx scripts/test-react-transition-runtime-imports.ts -> React runtime: addTransitionType=undefined ViewTransition=undefined Activity=symbol; no unsafe imports found.
• CI=true corepack pnpm exec tsc --noEmit --pretty false -> passed.
• CI=true corepack pnpm build -> compiled successfully and finished TypeScript; stopped during page-data collection because local DATABASE_URL is unset.

  

spent a lot of water and tokens to review your slop

Greptile Summary

This change introduces a compatibility layer for React transition APIs and a scanner intended to prevent unsupported direct imports from returning. The scanner correctly rejected a temporary direct ViewTransition import when run manually, but the automated deployment build command does not invoke it. As a result, a future unsupported import can be merged and deployed without the new safeguard running.

The transition-import scanner should be added to an automated required check before this change is merged.

Confidence Score: 4/5

Not safe to merge until the new transition-import guard is invoked by an automated required check.

A temporary unsafe import exercised the failure path: the scanner rejected it when run directly, while the deployment build command proceeded without running the scanner. This directly establishes that the intended regression protection is not enforced.

Files Needing Attention: package.json and the deployment workflow commands need to invoke scripts/test-react-transition-runtime-imports.ts; the scanner itself is at scripts/test-react-transition-runtime-imports.ts.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding, including a set of artifacts that help inspect the finding details.
• Authored an executable harness to toggle the temporary unsafe-import state and run both the direct checker and the CI build, enabling a reproducible before/after proof procedure.
• The harness output showed a clean direct checker pass and an unsafe-probe checker failure, while the CI build behavior remained unchanged.
• Direct-checker invocation independently validated by a separate log showing exit code 0 when run manually.
• Inspection of the automation/packing workflow confirmed npm run build is used without a checker invocation and that the workspace restoration was successful.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   React transition import guard is not wired into package or CI automation

   • Bug
     • scripts/test-react-transition-runtime-imports.ts can detect unsafe direct imports when invoked manually, but package.json exposes no script for it and neither tracked deployment workflow invokes it. A future unsafe direct React transition import can therefore pass the configured automated path without this guard running.
   • Cause
     • The new checker was added as a standalone file without adding it to package.json scripts or chaining it into the build/check steps used by .github/workflows/deploy-appservice.yml and azure-pipelines.yml.
   • Fix
     • Add a dedicated package script such as test:react-transition-runtime-imports: tsx scripts/test-react-transition-runtime-imports.ts, then invoke it in a required CI validation job or prepend it to every build/deployment path that must enforce the rule. Prefer a separate required CI step so its failure is explicit and is not masked by unrelated build prerequisites.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix: guard React transition runtime APIs" | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	examcooker	c86e2de	Sep 01 2026, 11:07 AM

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
examcooker-dev	Error		Sep 1, 2026 11:08am UTC

[greptile-apps]

Transition import guard is not automated

The scanner catches an unsafe ViewTransition import when run directly, but no package script or deployment build path invokes it. The deployment command remains npm run build, which does not run this scanner, so a future direct import of an unavailable React transition API can pass automated checks and restore the runtime crashes this change is intended to prevent. Add a package script for the scanner and invoke it from a required automated check.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Artifacts

Temporary unsafe-import automation harness

• This authored harness adds a disposable unsafe React transition import, runs the direct checker and CI build command before and after it, and removes the probe; the takeaway is a reproducible comparison of enforcement paths.

Checker and CI build output before and after unsafe import

• This captured run shows the checker passes before and fails after the unsafe import while the workflow’s `npm run build` command never invokes it; the takeaway is that CI does not enforce the checker.

Clean direct checker output

• This captured direct invocation exits successfully on the restored clean tree and reports no unsafe direct imports; the takeaway is that the guard works only when explicitly run.

Package and workflow invocation scan

• This captured scan finds build invocations in the deployment workflows but no reference to the transition-import checker, followed by restored-workspace status; the takeaway is that no package or workflow automation calls the guard.

_{Ran code and verified through T-Rex}