storage/dolt: migrate remaining in-tx DOLT_ADD/DOLT_COMMIT sites to post-tx ordering (lost-update hazard)

[steveyegge]

Summary

CALL DOLT_ADD / CALL DOLT_COMMIT executed inside a still-open SQL transaction can materialize a Dolt commit from the session's pre-merge transaction snapshot. Under concurrent writers on one branch this can silently write concurrently-committed rows back to their BEGIN-time values (lost updates). The mechanism is documented Dolt behavior history — dolthub/dolt#5205 and the dolthub/dolt#5608→#5621 staged-root-merge family — and PR #5740 reports reproducing the revert in production server mode and fixes the main issue-mutation path (runIssueOperationTxWithMessage) by moving the Dolt commit strictly after the SQL COMMIT.

This issue tracks the remaining in-tx surface, so the migration list lives somewhere that can't rot in a code comment.

Remaining in-tx DOLT_ADD/DOLT_COMMIT sites (as of current main)

• doltAddAndCommitInTx itself (internal/storage/dolt/ephemeral_routing.go) and its callers:
  • wisp promote / demote (ephemeral_routing.go)
  • legacy write paths in issues.go — UpdateIssue, UpdateIssueChecked, ClaimIssue, ClaimReadyIssue, UnclaimIssue, UnclaimIssueIfAssignee, ReclaimExpiredLeases, CloseIssue*, DeleteIssue*, MergeMetadata (several reachable from live CLI paths: bd edit/note/priority/defer/unclaim, linear sync)
  • slots.go (SlotClear)
  • RunInIssueLifecycleTransaction (transaction.go)
  • deleter.go stages via inline CALL DOLT_ADD in-tx as well
• Contrast: creates, comments, labels, and dependencies already use the post-tx doltAddAndCommit — the safe ordering this issue asks the remaining sites to adopt.

Acceptance

Every mutating path stages and Dolt-commits after its SQL transaction commits (post-merge working set), or documents a specific reason it cannot. doltAddAndCommitInTx is deleted or reduced to callers with a written justification. Sequence-contract tests in the style of PR #5740's dolt_commit_ordering_test.go pin the ordering for the migrated paths.

References

• PR fix(storage/dolt): run DOLT_ADD/DOLT_COMMIT after the SQL transaction commits (lost updates in server mode) #5740 (fixes the main path; hazard comment enumerates this surface)
• go/libraries/doltcore/sqle/dsess: When commiting a transaction with a DOLT_COMMIT, merge against the current HEAD if necessary. dolthub/dolt#5205, Concurrent table edits leaves uncommitted branch state dolthub/dolt#5608, dolthub/dolt PR graph --html: v1.1.2 still ships the pre-#4117 CSS, so the legend covers the graph #5621 (upstream mechanism, fixed early 2023 — a modern-server repro would be a live upstream regression worth reporting to dolthub)

[steveyegge]

Update from the #5740 thread (2026-08-14): @nova-submodules reports they have this migration already built on their fork — all remaining in-tx paths including wisp promote/demote, reopen, the lifecycle wrapper, and the inlined claim/close/update/delete/metadata sites, with the in-tx helper deleted outright. It caught a second production incident on their side (wisp patrol reverting concurrent claims). They plan to bring it forward against main as a follow-up PR once the #5740 rebase round lands — so this issue has a de-facto owner in flight; coordinate there before starting an independent migration.

Also relevant to severity: they confirmed the production repro was on dolt sql-server 2.2.x (2.2.3), i.e. after the 2023 dolthub#5205/#5608 fixes — a live modern-server regression, with a dolthub report to follow.