Blame for PERFORMANCE.md

# Performance checks

The API includes `Server-Timing` on JSON responses:

- `app`: server time until JSON serialization starts.
- `supabase`: summed response-header waits for Supabase requests started in this request, including auth. Parallel waits overlap, and shared in-flight work is counted only on the originating request.

Requests taking at least one second emit `slow_request` with a route template, status, elapsed time and upstream counts. No cookies, bodies, query parameters or user IDs are logged by this instrumentation. Streaming transfer time is not included in the JSON header.

Compare browser Network timings against these headers after deploying. High browser waiting time with low `app` time points toward transport/proxy latency; high `supabase` times identify upstream waits. Inspect authenticated list, detail, update and delete requests separately.

Read-only baseline from the development machine on 2026-10-20 (two requests per endpoint, not an authenticated benchmark):

| Endpoint | First | Second |
| --- | ---: | ---: |
| Public Space `/health` | 1006 ms | 787 ms |
| Public Space `/api/subscriptions` | 921 ms | 613 ms |
| Pages proxy `/api/subscriptions` | 1258 ms | 703 ms |

These samples include the development machine's network and do not establish a hosting bottleneck or a before/after improvement.

Changes reduce repeated profile reads after mutations, avoid writes on ordinary profile reads, coalesce concurrent authentication/role checks without caching completed permission decisions, and scope storage listings to one session. The storage listing APIs are documented at https://huggingface.co/docs/huggingface_hub/package_reference/hf_api.

The frontend keeps bounded, account-keyed summary snapshots in tab session storage for at most five minutes. Reloads display them while revalidating. Full analysis payloads are excluded; logout/account changes clear the cache. Server authorization remains required for every API request.

Remaining scaling work should follow production measurements: paginate large rosters and session lists, aggregate ratings in the database, and evaluate backend/database region placement. No production infrastructure or database changes were made here.


## 2026-10-21 follow-up

Active subscription and billing reads now embed the plan in the assignment query. Login profile synchronization skips writes for an unchanged email. Roster player/session reads start concurrently, action ratings join their actions, and Sessions embeds its optional player. Roster, detail and session list reads use stable ordered 500-row pages; action reads use batches of 100 session IDs with at most four batches in flight and paginate inside each batch. Authorization filters remain on every scoped parent read. No completed auth/role decisions are cached.

For small, non-admin, nonempty datasets, cold `/auth/me` uses three upstream calls rather than four; unchanged-profile login uses four rather than six. Players overview drops from six dependent stages to four; Sessions saves one total call while preserving its existing four-stage dependency depth. Large datasets require more pages. These are code-derived counts, not measured production latency. The new `workspace-performance.test.ts` runs the actual Express API against a local fake Supabase server and checks scopes, role changes, revocation, scores, billing and failures. `read-pages.test.ts` covers row-cap boundaries and failures.

The join shapes were verified read-only against the configured database. See [Supabase joins and nesting](https://supabase.com/docs/guides/database/joins-and-nesting) and [range pagination](https://supabase.com/docs/reference/javascript/range). The normal Supabase row cap must be at least the 500-row page size. No schema/dependency changes are needed. Full client-facing lists and squad aggregation remain scaling work. The root repository's `PERFORMANCE.md` records the broader audit and frontend bundle measurements.

Admin related counts now page and batch children of the displayed records. The admin Players page no longer scans unrelated sessions. Existing directory result caps remain; replacing them with full UI pagination remains follow-up work. Integration tests cover the three admin read endpoints as well.