fix(run-store,webapp): correct split-database read routing, write residency, and batches list ordering#4272
Conversation
…ads by run id In split mode these reads fanned out to both run-ops databases on every call. Route them by the run id already in scope so the non-owning database is no longer queried; only genuinely cross-tree waitpoints still need both.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (18)
WalkthroughThe change adds run-scoped waitpoint and snapshot routing with presence-aware pending counts and partitioned fallback reads. Standalone waitpoints, tags, and idempotency resets now support explicit residency routing. Batch listing uses merged split-store reads with createdAt/id composite keyset pagination. Tests cover routing, fallback, residency precedence, transaction handling, and pagination across residency boundaries. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…yed-waitpointsnapshot-reads
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
…ns on the run-ops DB by env mint kind A token created with no owning run (wait.createToken) mints a cuid id and routed to the legacy database by id-shape, so a fully-minted-new environment wrote its tokens to the draining legacy database instead of the run-ops database. Standalone tokens now read the env mint kind and pin to the run-ops database; co-located waitpoints still inherit their owning run's residency.
…y-key resets to the run-ops DB when the env mints run-ops ids Two env-scoped writes with no owning run to route by defaulted to the legacy database in a fully-minted-new environment: waitpoint tags (createWaitpointTag minted no id, so id-shape sent them to legacy) and idempotency-key resets (clearIdempotencyKey by predicate fanned out to both databases). Both now read the env mint kind and pin to the run-ops database, so they no longer write to the draining legacy database; a predicate reset with no mint signal still fans out.
…the new DB matches nothing Routing a predicate reset to the new database ONLY broke resets during the rollout window: a key minted before an org flipped still lives on a legacy-resident run (idempotency TTL up to 30 days), so a new-only reset matched zero rows, returned 404, and left the stale key deduping child triggers. The reset now checks the new database first and falls back to legacy when nothing matched, so it clears the key wherever the run lives; a fully-drained env still never touches legacy.
… some orgs The dashboard Batches list ordered and paginated by batch id, but batch id no longer reflects creation order for every batch, so some organizations could see older batches missing from the list or sorted above newer ones. The list now orders and paginates by creation time (with id as a stable tiebreak) and always reads both backing stores, so every batch appears exactly once, newest first.
d-cs
changed the title
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
… loaded on the env Guards against a missing environment.organization so the reset no longer crashes, falling back to the two-store reset in that case. The authenticated API path always loads the org, so behavior is unchanged in production.
…id date A malformed URL cursor could pass the finite-number check but still produce an invalid Date; it now falls back to the first page instead of reaching the query with an invalid date.
…edup-overlap regression, fix a routing comment
|
Thanks for the review. Addressing the three points: 1. Refill-after-dedup ( 2. Assert the complete composite cursor. Done. Both call sites now assert the exact 3. Routing comment in 4. The |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Use one createdAt per duplicated batch so both DB copies match exactly; two Date.now() calls could drift by a millisecond and the older copy would re-surface across pages under the createdAt keyset.
…yed-waitpointsnapshot-reads
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
2 participants
Summary
Correctness and performance fixes for deployments that split run data across more than one database. Single-database / self-hosted deployments are unaffected (they collapse to a single read/write path).
Notes
Verified end-to-end against multi-database setups: run-keyed reads and env-scoped writes land on the correct database with no cross-database writes, and the batches list surfaces every batch in creation order. New tests cover the batches ordering/reachability and the write-residency routing.