What did you do?
Ran the CSE test_random_cdc random test against a fresh PD/TiDB/CSE cluster with TiCDC new architecture enabled.
The test creates two keyspaces by default. For each keyspace, it creates a tpcc_ks<id> database, prepares a two-warehouse TPCC workload, and creates a keyspace-scoped TiCDC changefeed that replicates to a local downstream TiDB with sync points enabled. TPCC runs concurrently for each keyspace using four threads in repeated 10-second runs. After the workload stops, the test waits for the changefeeds to reach the target TSO and validates upstream/downstream consistency with sync-diff.
What did you expect to see?
TiCDC should process the concurrent TPCC changes without panicking, advance each changefeed checkpoint to the target TSO, and allow the final sync-diff consistency check to pass.
What did you see instead?
TiCDC panicked while generating batch SQL in unsafe mode:
[2026/09/19 05:57:15.732 +00:00] [PANIC] [mysql_writer_dml_batch.go:384] ["invalid rows when generating batch SQL in unsafe mode"] [error="[CDC:ErrUnexpected]cdc met unexpected error: duplicate rows for update and insert"]
The panic occurred while processing physical table ID 134 (tpcc_ks1.stock). Immediately before the panic, TiCDC logged the per-event SQL using normal sql should be. The conflicting events contain repeated identical row keys, and buildRowChangesForUnSafeBatch rejects an update/insert pair with the same key.
This appears related to closed issue #1256, which reported the same MySQL writer generateBatchSQLInUnsafeMode panic path under the earlier message invalid row changes. Its linked workaround PR #1280 was closed without merging. This occurrence is in the current batch implementation and reports the more specific invariant failure duplicate rows for update and insert.
Versions of the cluster
TiDB (CSE):
Release Version: v8.5.3-serverless
Git Commit Hash: 20260917-a4482a4f81a45fd72a6c8a3290ce6a4ec6937037
Git Branch: main-8.5-keyspace
UTC Build Time: 2026-09-17 07:14:07
GoVersion: go1.24.4
TiKV (CSE):
Version: 26.3.0-cse
Git Hash: 39b0af4b77b41dd6e34e381ffe7ccd8388b81e44
PD (CSE):
Release Version: v8.5.0-serverless
Git Commit Hash: e9bf919d701db7971a8c17683acb4d02704859af
Git Branch: release-8.5-keyspace
UTC Build Time: 2026-08-20 03:44:17
TiCDC:
Release Version: v8.5.4-nextgen.202510.5-397-gcf33e2a
Git Hash: cf33e2a9da928e98c0c923b898613a7c94e26656
Git Branch: HEAD
UTC Build Time: 2026-09-16 11:44:53
GoVersion: go1.25.12 linux/amd64
Kernel Version: Next Generation
What did you do?
Ran the CSE
test_random_cdcrandom test against a fresh PD/TiDB/CSE cluster with TiCDC new architecture enabled.The test creates two keyspaces by default. For each keyspace, it creates a
tpcc_ks<id>database, prepares a two-warehouse TPCC workload, and creates a keyspace-scoped TiCDC changefeed that replicates to a local downstream TiDB with sync points enabled. TPCC runs concurrently for each keyspace using four threads in repeated 10-second runs. After the workload stops, the test waits for the changefeeds to reach the target TSO and validates upstream/downstream consistency with sync-diff.What did you expect to see?
TiCDC should process the concurrent TPCC changes without panicking, advance each changefeed checkpoint to the target TSO, and allow the final sync-diff consistency check to pass.
What did you see instead?
TiCDC panicked while generating batch SQL in unsafe mode:
[2026/09/19 05:57:15.732 +00:00] [PANIC] [mysql_writer_dml_batch.go:384] ["invalid rows when generating batch SQL in unsafe mode"] [error="[CDC:ErrUnexpected]cdc met unexpected error: duplicate rows for update and insert"]The panic occurred while processing physical table ID
134(tpcc_ks1.stock). Immediately before the panic, TiCDC logged the per-event SQL usingnormal sql should be. The conflicting events contain repeated identical row keys, andbuildRowChangesForUnSafeBatchrejects an update/insert pair with the same key.This appears related to closed issue #1256, which reported the same MySQL writer
generateBatchSQLInUnsafeModepanic path under the earlier messageinvalid row changes. Its linked workaround PR #1280 was closed without merging. This occurrence is in the current batch implementation and reports the more specific invariant failureduplicate rows for update and insert.Versions of the cluster
TiDB (CSE):
TiKV (CSE):
PD (CSE):
TiCDC: