feat(run-ops): activation — drop cross-DB FKs, provision run-ops DB, enable split#4124
Conversation
|
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)
📜 Recent review details⏰ Context from checks skipped due to timeout. (24)
🧰 Additional context used📓 Path-based instructions (1)**/Dockerfile*📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🔇 Additional comments (1)
WalkthroughThis PR removes Prisma relation fields and matching foreign keys for run-ops and control-plane entities, drops the 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
d-cs
force-pushed
the
runops/pr10-activation
branch
from
76dabfd to
dffb0d2
Compare
|
![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.
@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: |
|
On the out-of-diff finding that TaskRunAttempt (backgroundWorker/backgroundWorkerTask/runtimeEnvironment) and TaskRunTag (project) still declare @relation for the FKs dropped in 20260629120000: this is intentional and mirrors TaskRun itself, which keeps its project/runtimeEnvironment relations after its cross-DB FKs were dropped earlier in the series. These relations are never JOINed on the dedicated run-ops DB — the run store strips them from Prisma selects and rehydrates from scalar columns. The BatchTaskRun scalarization was a special case (its relation had no consumers). Prisma-migrate won't re-add these in the managed flow: hand-dropped constraints are an accepted drift condition throughout this schema. Also fixed the one genuine consumer regression flagged inline: PerformBulkActionService now uses scalar groupId queries and reads the action kind from BulkActionItem.type instead of the removed group/items relations. Verified with a green webapp typecheck against a freshly regenerated client. |
d-cs
force-pushed
the
runops/pr10-activation
branch
from
3aa59bd to
3276836
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
3276836 to
25312fc
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
25312fc to
8b6bb5a
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
8b6bb5a to
806b7bb
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
806b7bb to
1a72386
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
2 times, most recently
from
d338e32 to
af028f7
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
af028f7 to
fb0bb45
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
fb0bb45 to
fbd7cb9
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
fbd7cb9 to
af3338a
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
af3338a to
f27fb06
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
fc4be3c to
a5b52e5
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
a5b52e5 to
4744063
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
4744063 to
335e3d6
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
335e3d6 to
faa1854
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
faa1854 to
f51b285
Compare
d-cs
force-pushed
the
runops/pr10-activation
branch
from
f51b285 to
9806c65
Compare
…ps DB, enable split Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…11 activation tests Remove Test A–F enumeration prefixes from the run-ops cascade-cleanup comments and the RED/GREEN TDD framing from the ProjectAlert control-plane FK reconciliation test header. Comment-only; no product logic, test behavior, or migration SQL changed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ion drop The activation schema removed the BulkActionGroup.items and BulkActionItem.group Prisma relations, but PerformBulkActionService still queried them via include, which would fail once the client regenerates. Switch to scalar groupId lookups and read the action kind from BulkActionItem.type. Also drop a stale test comment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
d-cs
force-pushed
the
runops/pr10-activation
branch
from
9806c65 to
b3e0709
Compare
…-locking drops last for safe prod deploy These FK/table drops take ACCESS EXCLUSIVE on huge hot tables (TaskRun, Waitpoint, TaskRunAttempt, RuntimeEnvironment, Project). Without a lock_timeout a migration can queue behind a long VACUUM/transaction and hang the whole platform, so set lock_timeout = '5s' at the top of each migration to fail fast and roll back cleanly. Also make the two remaining DROP CONSTRAINTs idempotent with IF EXISTS, matching the others, and reorder so the two migrations that lock TaskRun run last (rename the join-table drop to 20260630130000). That way a lock_timeout fail-fast leaves the cheap FK drops already applied. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…he image The runner image only copied @trigger.dev/database's generated client, so a split-ON deployment would hit a missing query engine when constructing RunOpsPrismaClient. Generate the run-ops-database client in dev-deps and copy internal-packages/run-ops-database/generated into the runner. No-op for single-DB/no-flags deploys (client is never constructed). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
What
The activation PR for the run-ops database split. This is the behaviour-changing top of the stack: it drops the cross-database Prisma foreign keys, provisions the dedicated run-ops database, and enables the split.
Schema (
schema.prisma): removes the Prisma relations that span what is now a database boundary —RuntimeEnvironment.batchTaskRuns,TaskRun.tags,TaskRun.alerts,TaskRunTag.runs,TaskRunAttempt.alerts,BatchTaskRun.runtimeEnvironment,BulkActionGroup.items,BulkActionItem.group, and theProjectAlert.taskRun/taskRunAttemptrelations. The underlying scalar id columns are kept; the relationships are resolved through the run store instead of a DB-level FK.ProjectAlertgets a comment explaining why those references are now scalar-only.Migrations: five FK-drop migrations —
drop_task_run_to_task_run_tag_joindrop_bulk_action_item_group_fkdrop_batch_task_run_environment_fkdrop_run_ops_control_plane_foreign_keysdrop_project_alert_run_subgraph_foreign_keysThese remove the cross-subgraph foreign key constraints so run-subgraph rows can live on the dedicated run-ops database.
Enables the split at runtime.
Tests cover the FK drops (
batchTaskRunEnvironmentFkDrop,dropTaskRunToTaskRunTagJoin,PostgresRunStore.controlPlaneAlertFk) and the cascade-cleanup behaviour that the store now owns in place of the dropped DB cascades (runOpsCascadeCleanup).Why
Part of the run-ops database split. This is PR10 of the series (PR8/9/10) and is the one that actually changes behaviour: it flips the split on. It depends on all prior PRs in the series being merged first — the read presenters (PR8) and the route wiring (PR9) must be in place before the split is enabled, or reads and token resolution across the boundary will break.
Note that the FK-drop migrations run regardless of the runtime split flag: dropping the constraints is a schema fact, and the migrations apply on deploy whether or not the split is switched on at runtime. This is intentional — the constraints cannot hold once run-subgraph rows may live on a separate database.
Tests
pnpm run test --filter @internal/database/--filter webappfor the FK-drop and cascade-cleanup suites. The cascade-cleanup suite verifies the store-side deletes that replace the dropped DB-level cascades.Notes
Draft, stacked on #4123 (
runops/pr09-routes). Review that first; this diff is against it.Server-change / changeset note to be added at stack-assembly time.
🤖 Generated with Claude Code