fix(run-store): stop run-create failing on a brief write stall

[ericallam]

Summary

On the run-ops store, creating a run could intermittently fail with a "Transaction already closed" error, and the run would never be created. Single-write run creates no longer run inside an interactive transaction, so a brief database write stall can't blow the transaction budget and drop the run.

Fix

The dedicated run-ops createRun / createFailedRun wrapped a single nested taskRun.create in an interactive $transaction. Its default 5s budget is wall-clock from BEGIN, so when a write briefly stalls the transaction expires before the create completes and throws, even though the statement itself is fast at the database.

A single-write create does not need an interactive transaction: Prisma's implicit nested create is already atomic and holds no app-side budget, so it now runs directly. Only the triggerAndWait path (run plus its associated waitpoint, two writes that must commit together) keeps an interactive transaction, now with headroom over the default.

Verified with a red/green test against the real split topology (reproduces the exact expiry on the unchanged code, green after) and an end-to-end run created and completed through the dedicated store.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 075c12b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

The run store now accepts transaction options and defines a 15-second write timeout. Dedicated createRun and createFailedRun paths use a single write when no waitpoint exists. They use the configured timeout when creating a run with a waitpoint. An integration test verifies run and execution snapshot persistence when interactive transactions time out after 1 ms. A server change note documents the fix.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the run-store fix for failures caused by brief write stalls.
Description check	✅ Passed	The description clearly explains the fix and includes verification details, although it omits the template's issue link and checklist sections.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/tri-12968-fix-5s-interactive-transaction-timeout-fails-68-run

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.