refactor(run-engine,webapp): route TaskRun writes through a new RunStore adapter#3981
Conversation
Replaces the seven throwing stubs on PostgresRunStore with verbatim relocations of the Prisma statements from runAttemptSystem: startAttempt, completeAttemptSuccess, recordRetryOutcome, requeueRun, recordBulkActionMembership, cancelRun, and failRunPermanently. Each method splices the caller-supplied select/include into the Prisma call. Tests use real Postgres containers and cover each method including edge cases (append semantics, conditional fields in cancelRun).
…y-clear, and array-append methods
Replaces the seven throwing stubs in PostgresRunStore with verbatim-relocated
Prisma statements sourced from delayedRunSystem, debounceSystem, updateMetadata,
idempotencyKeys, resetIdempotencyKey, batchTriggerV3, and the realtime-stream
route handlers.
- rescheduleRun: writes delayUntil always; queueTimestamp when provided; nested
DELAYED executionSnapshot when snapshot arg provided
- enqueueDelayedRun: sets status PENDING + queuedAt
- rewriteDebouncedRun: pass-through update with associatedWaitpoint include
- updateMetadata: optimistic-lock path (updateMany with version predicate) or
direct path (update without predicate); both return { count }
- clearIdempotencyKey: three discriminated-union branches — byId clears both
columns, byPredicate clears both, byFriendlyIds clears only idempotencyKey
- pushTags: push-append to runTags array; returns { updatedAt }
- pushRealtimeStream: push-append to realtimeStreams array; returns void
…bapp BaseService Add RunStore field to SystemResources, instantiate PostgresRunStore in RunEngine constructor (after prisma/readOnlyPrisma are set), and expose it on the resources object passed to all systems. Create a webapp singleton (runStore.server.ts) and thread it as a default parameter into BaseService so subclasses can access it without changes.
…eave-unchanged semantics)
…s through RunStore
… debounce writes through RunStore
… writes through RunStore
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
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 ignored due to path filters (1)
📒 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 of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (40)
WalkthroughThis PR introduces a new 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
@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: |
The service statically imported the db.server-backed runStore singleton, which dragged the Prisma client into otherwise-light test module graphs and opened an eager connection to DATABASE_URL on import. The metadata service test then threw an unhandled connection error whenever no database was reachable at the configured address. Make runStore a required constructor option, pass the singleton at the production construction site, and inject a testcontainer-backed store in the tests.
Summary
Introduces
@internal/run-store, a typed layer that TaskRun writes go through, and routes the existing directprisma.taskRun.*writes from the V2 run engine and the shared webapp services onto it. The deprecated V1 engine write paths are intentionally left as-is (they write directly toTaskRun). This is a behavior-preserving refactor: the same rows are written, with the same SQL, against the same table. It puts V2 and shared run persistence behind one interface, so future storage changes have a single seam instead of writes scattered across many call sites.Design
RunStoreexposes one method per run-lifecycle write (create, dequeue lock, attempt start/complete/fail, retry, cancel, expire, checkpoint suspend and resume, delay and reschedule, debounce, metadata, idempotency-key clear, tag and stream append).PostgresRunStoreimplements each as the exact write the call site performed before, against the existingTaskRuntable. ANoopRunStoreis provided for tests.The V2 run engine reaches the store through a new field on its shared system resources; the webapp reaches it through a base-service member and a server singleton. Every method accepts an optional transaction client, so in-transaction writes are unchanged.
Behavior is covered by unit tests for each store method (real Postgres via testcontainers) and by the existing run-engine suite staying green.