fix: guard React transition runtime APIs

[cursor]

Bug and impact

React 19.2.8 in this repo does not export addTransitionType or ViewTransition at runtime. Several navigation/search/filter components imported those APIs directly from react, so user interactions that call addTransitionType could throw immediately, and pages rendering <ViewTransition> could crash with an invalid element type. This breaks core navigation/search/past-paper flows.

Root cause

The app followed Next 16 canary view-transition docs and TypeScript canary typings, but the pinned React runtime lacks the corresponding exports.

Fix

• Added a shared app/components/common/react-transition.tsx compatibility module.
• Routed all addTransitionType calls through a no-op-safe wrapper.
• Routed <ViewTransition> usages through an optional wrapper that renders children unchanged when the runtime component is absent.
• Added scripts/test-react-transition-runtime-imports.ts to prevent direct unsafe value imports from react returning.

Validation

• CI=true corepack pnpm exec tsx scripts/test-react-transition-runtime-imports.ts ✅ (addTransitionType=undefined ViewTransition=undefined, no unsafe imports)
• CI=true corepack pnpm build ✅ compiled successfully and finished TypeScript; stopped later during page-data collection because DATABASE_URL is unset in this environment.

  

spent a lot of water and tokens to review your slop

Greptile Summary

This change adds compatibility wrappers for React transition APIs that are absent from the deployed React runtime and introduces a scanner for unsafe direct imports. The scanner detects an injected unsafe React transition import when run directly, but normal package and deployment builds do not invoke it; the same import compiles successfully through npm run build. Connect the scanner to required package and deployment checks before merging.

Confidence Score: 4/5

Not ready to merge until the React transition import scanner is required by the normal build and deployment checks.

The unsafe-import path was exercised directly: the scanner rejected the injected import, while the configured build path compiled that same import without running the scanner. Package scripts and both deployment configurations were inspected to confirm the missing integration.

Files Needing Attention: package.json, .github/workflows/deploy-appservice.yml, azure-pipelines.yml, and scripts/test-react-transition-runtime-imports.ts need to be connected so the existing guard runs automatically.

T-Rex Logs

What T-Rex did

• Generated a proof for a posted P1 finding using a temporary import validation harness and ran scanner checks on a clean tree.
• Compared the scanner and build outputs between the clean tree and the tree with the temporary unsafe React import, and captured the results as artifacts.
• The contract validation showed the scanner detects the relevant runtime-import issue at scripts/test-react-transition-runtime-imports.ts:36-70 and exits nonzero at :84-91.
• The validation found that npm run reports no scanner/check/test script and that workflows only reference npm run build in CI configurations.
• The unsafe-import build compiled successfully but stopped because DATABASE_URL was missing in db/index.ts, indicating an environment limitation rather than a code issue.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   React transition runtime-import guard is not part of automated package or CI checks

   • Bug
     • The scanner exists and detects a temporary import { addTransitionType } from "react"; probe, exiting 1. However, it is not registered in package.json scripts (package.json:5-39) and neither CI workflow invokes it: GitHub Actions runs only npm run build (.github/workflows/deploy-appservice.yml:76-82), while Azure Pipelines likewise runs only npm run build (azure-pipelines.yml:52-109). The injected import compiled under npm run build, proving that the configured automated path does not run this guard.
   • Cause
     • The scanner was added as a standalone TypeScript file without wiring it into a package script, build/check pipeline, or CI workflow step.
   • Fix
     • Add a root check script such as test:react-transition-runtime-imports: tsx scripts/test-react-transition-runtime-imports.ts, include it in a mandatory CI check (preferably before the build), and invoke that check from every deployment/build workflow rather than relying on an undocumented direct command.

   _{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	d6a7c80	Aug 23 2026, 11:05 AM

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
examcooker-dev	Error		Aug 23, 2026 11:05am

[greptile-apps]

React transition import guard is not automated

The scanner correctly rejects a direct addTransitionType import, but it is not registered in any root package script or invoked by either deployment workflow. A temporary unsafe import still compiled successfully through npm run build, so the compatibility failure this scanner is meant to prevent can be reintroduced without automated checks catching it. Add a named check script for this scanner and run it in every build and deployment workflow before the application build.

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 import validation harness source

• Review-authored harness source that runs the clean and injected-import scanner and build commands, records outputs, and removes the temporary probe; the takeaway is that the evidence was generated reproducibly without permanent source changes.

Scanner output on the clean tree

• The direct scanner command completed with exit code 0 and reported no unsafe React transition runtime imports; the takeaway is that the baseline tree passes the standalone guard.

Scanner output with the temporary unsafe React import

• After adding a temporary app probe importing addTransitionType from React, the direct scanner exited 1 and named the exact import; the takeaway is that the standalone scanner itself works.

Root npm script inventory

• The executed `npm run` inventory lists all root scripts and contains no transition-import scanner, test, check, or CI script; the takeaway is that normal package-script automation cannot invoke this guard.

Workflow command references

• The executed workflow search found only `npm run build` in the GitHub Actions and Azure Pipelines configurations and no scanner reference; the takeaway is that configured CI does not invoke the guard.

Build output on the clean tree

• The clean `CI=true npm run build` compiled successfully before failing during page-data collection because DATABASE_URL was absent; the takeaway is that the build path was exercised to the point where source compilation completed.

Build output with the temporary unsafe React import

• The same build with the temporary unsafe import also compiled successfully and failed only on the same missing DATABASE_URL, without scanner output; the takeaway is that the automated build path does not catch the unsafe import.

Repository restoration check after validation

• The executed cleanup restored the build-generated tracked file and status shows only pre-existing/tool artifact directories as untracked; the takeaway is that no repository source change from the validation remains.

_{Ran code and verified through T-Rex}