ci(webapp): wire the run-ops legacy guard into CI and add oxlint residency fences#4279
Conversation
…-ops handle CancelTaskRunService.callV1 finalizes historical (engine V1) runs, which are legacy-resident. It wrote them through the control-plane client, which misses the row once legacy run-ops data lives on its own database. Route those two writes through runOpsLegacyPrisma, matching every other legacy run-graph write.
Run apps/webapp/scripts/runOpsLegacyGuard.ts --check as its own PR job so new code that reaches a run-graph table through the control-plane client (instead of the RunStore) fails the build. Add fast in-editor oxlint rules (trigger-runops plugin) covering the direct-call and read-through-slot cases, scoped to apps/webapp/app. Regenerate the guard baseline, which had drifted stale.
|
|
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 (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (23)
🔇 Additional comments (1)
WalkthroughThe changes add and configure the 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
…nt of build state The guard resolved the Prisma client packages through their built dist/, which the CI job does not build (install + generate only). That left every client type unresolved in CI, so the guard classified nothing as control-plane and reported 0 violations - blind, and would rubber-stamp a real leak. Pin resolution to the checked-in sources, match declaration files against absolute generated-client dirs, and add a preflight + classification anchors that exit non-zero rather than pass blind.
Swap cancelTaskRun's V1 finalize writes from runOpsLegacyPrisma (control-plane typed, needed a runops-legacy-ok annotation) to the branded runOpsLegacyPrismaClient, which the guard classifies as run-ops. Same legacy writer at runtime; drops the two annotations and their baseline entries. Matches the existing legacyWriter usage.
What
apps/webapp/scripts/runOpsLegacyGuard.ts --checkas its own PR job (runops-guard), so code that reaches a run-graph table through the control-plane Prisma client instead of the RunStore fails the build.trigger-runopsoxlint plugin with two fast, in-editor rules scoped toapps/webapp/app: one for directprisma.taskRun-style access, one for a control-plane client wired into a read-through slot. These are the cheap fence; the guard is the type-aware gate.CancelTaskRunService.callV1: historical V1 runs are legacy-resident, so its two finalize writes now go throughrunOpsLegacyPrismainstead of the control-plane client (they'd miss the row once legacy is a separate database).Why
The guard existed but ran nowhere, so its baseline rotted and a real residency gap (the V1 cancel writes) sat undetected. Wiring it into CI turns it into a ratchet against new control-plane run-graph access.
Verification
Local, against a clean regen:
oxfmt --check,oxlint .,guard --check, andtypecheck --filter webappall pass. Remaining baseline entries are 4 batch-results router reads through type-opaqueas PrismaReplicaClientcasts (correct at runtime, accepted) + 2 sanctioned legacy annotations.