Test Cassandra bypass-current concurrency fences

[taylan-oai]

Summary

Document and test the existing Cassandra bypass-current safeguards so changes to current-run promotion preserve execution-version and shard-ownership checks.

Problem

Cassandra checks that a run is not current before submitting its mutable-state batch. Existing tests cover current-record conflicts and execution-version conflicts separately, but do not exercise a current-run transition between this read and the batch. The relationship between this precheck, History's execution lock, and the conditional writes is also undocumented.

Approach

Add deterministic Cassandra integration tests that execute a competing persistence operation after the bypass-current read and before the conditional batch. Cover both update and conflict resolution:

• Promoting the target run changes its database version in the same batch, rejecting the stale bypass write even when its next event ID stays unchanged.
• With no current record, creating the same run fails because the execution already exists; creating a different current run allows the bypass write to finish.
• A shard ownership change rejects the stale batch without changing the execution.

Read back complete mutable state and the current run after each operation. Document the History execution-lock and shard-fencing assumptions beside the precheck.

Validation

• Native changed-code lint passed.
• Eight new deterministic interleavings passed against Cassandra 5.0.9, including a run with the Go race detector.
• The complete Cassandra mutable-state suite passed alongside the new tests.
• Cassandra package unit tests and the workflow cache suite passed.
• Existing workflow-cache concurrent-access coverage passed with the Go race detector.

Risks, rollout, and scope

Runtime behavior and schema are unchanged. The positive database-version argument does not apply to legacy executions with DBRecordVersion == 0 when the next event ID is unchanged; those executions rely on History's per-run lock and shard fencing. These tests do not establish safety for arbitrary direct database writes or callers that bypass those ownership rules.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}