Jepsen append workload fails with g-single anomaly

[overvenus]

Bug Report

I've written a script that runs Jepsen with random workloads, nemesis, and configurations, which reports g-single anomaly in the append workload, indicating that Snapshot Isolation is likely broken.

Jepsen log:

Let:
  T1 = {:type :ok, :f :txn, :value [[:r 2285 [2 4 5 3 1 7 10 11 12 8 9]] [:r 2290 nil] [:r 2287 [1 4 3 5 7 9 10 6 11 8 12 2 13 14 15]]], :process 122, :time 296868431173, :txn-info {:txn_scope "global", :start_ts 454732492355928212, :commit_ts 454732492355928257, :txn_commit_mode "2pc", :async_commit_fallback false, :one_pc_fallback false, :pipelined false, :flush_wait_ms 0}, :index 60260}
  T2 = {:type :ok, :f :txn, :value [[:append 2287 15] [:append 2290 2] [:r 2288 [3 4 5 6 7]]], :process 80, :time 296862495111, :txn-info {:txn_scope "global", :start_ts 454732492355928210, :commit_ts 454732492355928222, :txn_commit_mode "async_commit", :async_commit_fallback false, :one_pc_fallback false, :pipelined false, :flush_wait_ms 0}, :index 60256}

Then:
  - T1 < T2, because T1 observed the initial (nil) state of 2290, which T2 created by appending 2.
  - However, T2 < T1, because T1 observed T2's append of 15 to key 2287: a contradiction!

The cause is unclear, and it may be due to misconfigured settings or an actual bug.

The full logs can be found in step 4. https://tcms.pingcap.net/dashboard/executions/plan/7529764

1. Minimal reproduce step (Required)

Rerun the test in the above link.

2. What did you expect to see? (Required)

No failure.

3. What did you see instead (Required)

See above.

4. What is your TiDB version? (Required)

1fa2955

[zyguan]

It's expected since the test ran with txn-mode=mixed and use-index=true, that is, select for update in a pessimistic transaction actually cannot lock the row.