amal66 stops project pickers from hammering the platform

Opening a project picker now makes one coordinated request instead of triggering a burst of lookups for every project.

workflowinfrastructure

amal66 has tackled a failure mode that would be painfully familiar to any growing legal team: a simple selection screen becoming unreliable once the account holds dozens of matters.

The document, workflow and assistant pickers previously requested extra detail separately for each project as they opened. Under concurrent use, that multiplied authentication and database traffic enough to cause gateway errors and flaky screens. The revised approach can return the needed document information alongside the initial project list, while leaving ordinary project listings unchanged when that detail is not needed.

The team tested the same high-pressure scenario that had caused failures, with multiple pickers opening at once and new projects being created, and reported no failed requests or gateway errors. Repeated end-to-end checks also completed without retries.

So what Legal teams building large matter libraries should care because routine navigation is now designed to stay dependable as project volume and simultaneous use rise.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

36cddb25 fix: batch directory-modal project fetch instead of N+1 getProject burst QA Runner 2026-07-20 ↗ GitHub

SHA	Subject	Author	Date
`36cddb25`	fix: batch directory-modal project fetch instead of N+1 getProject burst	QA Runner	2026-07-20	↗ GitHub
commit body Every directory picker (AddDocumentsModal, UseWorkflowModal, the assistant project selector) loads its "Projects" tab through useDirectoryData, which fired one GET /projects/:id for EVERY existing project the moment the modal opened. Each of those requests costs an auth verification against GoTrue plus ~6 PostgREST queries, so an account with N projects produced an ~8xN-request burst on the Supabase gateway per modal open. Under that burst the gateway genuinely falls over: measured locally against the Supabase CLI stack, overlapping modal-open storms drove GoTrue into Postgres connection exhaustion ("failed to connect ... context deadline exceeded") and produced 467x 500 + 641x 504 on /auth/v1/user in a single run - surfacing to users as failed project creates/loads, and to the e2e suite as the intermittent Kong 502s its specs currently retry around. Fix: GET /projects now accepts ?include=documents and returns each project's documents from one batched query (same attach helpers as GET /projects/:id, run once across all documents), and useDirectoryData uses it. A modal open is now 1 API request and a fixed number of DB queries regardless of project count. After the change the same storm harness produced zero 5xx and zero auth failures. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

commit body

Every directory picker (AddDocumentsModal, UseWorkflowModal, the assistant
project selector) loads its "Projects" tab through useDirectoryData, which
fired one GET /projects/:id for EVERY existing project the moment the modal
opened. Each of those requests costs an auth verification against GoTrue
plus ~6 PostgREST queries, so an account with N projects produced an
~8xN-request burst on the Supabase gateway per modal open.

Under that burst the gateway genuinely falls over: measured locally against
the Supabase CLI stack, overlapping modal-open storms drove GoTrue into
Postgres connection exhaustion ("failed to connect ... context deadline
exceeded") and produced 467x 500 + 641x 504 on /auth/v1/user in a single
run - surfacing to users as failed project creates/loads, and to the e2e
suite as the intermittent Kong 502s its specs currently retry around.

Fix: GET /projects now accepts ?include=documents and returns each
project's documents from one batched query (same attach helpers as
GET /projects/:id, run once across all documents), and useDirectoryData
uses it. A modal open is now 1 API request and a fixed number of DB
queries regardless of project count. After the change the same storm
harness produced zero 5xx and zero auth failures.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1346.md from inside the repo you want the changes in.

⬇ Download capture-thread-1346.md