[aamoghS]

Server prefetch for the remaining portal pages (#584).

---

Note

Low Risk
Mostly routing and data-loading structure with no API or permission changes; hackathon list prefetch scales with edition count and could add server work on large lists.

Overview
Completes server-side tRPC prefetch for the admin portal routes that were still client-only: analytics, initiatives, projects, resumes, staff, and subteams. Each route’s UI moves into a dedicated client *Page.tsx, while page.tsx becomes a thin server wrapper around PrefetchedPage so the first queries hydrate into React Query before paint.

Hackathon admin prefetch is broadened: the list page now awaits listAll and prefetches getEvents for every card; the edition dashboard prefetches waveStatus and registrationOpenEmailStatus based on hackathon status after getById resolves.

Event check-in UI is extracted into CheckInPage.tsx (behavior unchanged; supports the same prefetch/split pattern as other portal routes).

^{Reviewed by Cursor Bugbot for commit 79d4dfb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

@greptileai

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[github-actions]

Visit the preview URL for this PR (updated for commit 79d4dfb):

https://hacklytics2027--pr-585-jqkqjzoj.web.app

_{(expires Sat, 14 Nov 2026 17:39:27 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: c48ba34db61581e25fe2978355160b5eefe0e83f}

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The change reaches initial data loading across several portal workflows.

Fix the delayed rejection handler for listBans() before merging.

Findings

1.  Query errors escape the fallback ▶

Summary

Adds server prefetches for the remaining portal pages.

• Admin dashboards and lists start with their first data ready.
• Admin hackathon pages preload the data their lists and tabs need.
• Hackathon and registration pages preload data for their opening views.
• The judge desk preloads the data for panels its context enables.
• Both scan desks preload data for their opening views.

One error-handling issue remains: listBans() can reject before its handler attaches.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Portal page] --> B[PrefetchedPage]
  B --> C[Get signed-in caller]
  C --> D[Run initial reads]
  D --> E[Settle results]
  E --> F[Hydrate successful results]
  F --> G[Client queries use cached data]
  E --> H[Failed reads retry in browser]

Loading

_{Reviews (1) · Last reviewed commit: "Merge pull request #584 from DataScience..." · Reviewed by Greptile}

[greptile-apps]

Query errors escape the fallback

listBans() starts before await all, but nothing catches its rejection until reads() returns. If the bans query fails while listAll() is still waiting on the database, the server gets an unhandled rejection instead of skipping the failed prefetch. This can disrupt the admin page or its server worker. Attach a rejection handler immediately, or start listBans() after the wait, so database errors keep the intended client-side fallback.