Conversation
❌ Test FailureAnalysis: Test_PartitionBy fails deterministically across all 4 test suites with a consistent assertion mismatch (expected partition key "num" but got "(num)"), indicating a real behavioral change — likely a newer ClickHouse version now wraps PARTITION BY expressions in parentheses. |
❌ Test FailureAnalysis: Test_CDC_V2_Protocol deterministically times out (200s) across all matrix jobs with other.NumRecords stuck at 1 instead of 2, indicating a real replication bug likely related to the ClickHouse ORDER BY/PARTITION BY change only partially fixed in the previous commit. |
🔄 Flaky Test DetectedAnalysis: Test_CDC_V2_Protocol times out at ~200s across all three matrix variants (199.33s–200.26s), indicating it's hitting an internal deadline rather than a real assertion failure, causing the overall e2e suite to exhaust the 900s timeout. ✅ Automatically retrying the workflow |
🔄 Flaky Test DetectedAnalysis: All failures are timeout errors ("UNEXPECTED TIMEOUT waiting on initial", "UNEXPECTED TIMEOUT v2 single insert", "context deadline exceeded" on Temporal) across all three CI matrix jobs, indicating overloaded CI runners rather than a code regression. ✅ Automatically retrying the workflow |
❌ Test FailureAnalysis: Test_CDC_V2_Protocol fails deterministically across all 3 matrix configurations (~200s each), consistent with a real regression likely introduced by the recent ClickHouse PARTITION BY/ORDER BY change rather than a flaky environment issue. |
🔄 Flaky Test DetectedAnalysis: The e2e test suite for the maria/8.0 matrix job hit the hard 900-second timeout and was killed mid-run, with no assertion failures, indicating infrastructure slowness or a stuck test rather than a code regression. ✅ Automatically retrying the workflow |
❌ Test FailureAnalysis: Test_NullEngine deterministically fails in all 4 test suites (MySQL_CH, MySQL_CH_Cluster, PG_CH, PG_CH_Cluster) because the ClickHouse NullEngine table never accumulates records (other.NumRecords stays at 0 across every polling cycle), which is likely a real regression from the recent ClickHouse version behavior change (the prior commit already patched PARTITION BY/ORDER BY issues from the same upgrade). |
Code reviewBug: v2 state not propagated through Lua stream adapterFile:
The result: The stream adapter already propagates |
❌ 1 Tests Failed:
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
🔄 Flaky Test DetectedAnalysis: TestRunPipeline_DstExitsNonZero is racy: src got SIGPIPE because dst exited before reading the pipe, and goroutine scheduling determined whether "src failed" or "dst failed" was reported — the test assumes dst's Wait() always completes first, which isn't guaranteed. ✅ Automatically retrying the workflow |
ilidemi
left a comment
There was a problem hiding this comment.
Fun stuff! First pass, haven't looked into details of CDC pull or schema changes yet
| // possible. Without this guard a small streamed txn whose Commit arrives | ||
| // shortly after StreamStop could be split across two batches, leaving the | ||
| // records orphaned in the WAL sink with no committedXID to normalize. | ||
| inProgressStreams := p.inStream || len(p.activeStreams) > 0 |
There was a problem hiding this comment.
If PG has events
start stream tx1
insert
stop stream
begin tx2
insert
commit
start stream tx1 (resume)
insert
then no WAL activity for some time, do we know for sure the stop stream will come right away to unblock tx2?
| // WHERE clause: WAL sink mode filters by committed XIDs, v1 mode filters by batch_id range | ||
| if t.walSinkMode { | ||
| fmt.Fprintf(&selectQuery, | ||
| " FROM %s WHERE _peerdb_txid IN (%s) AND _peerdb_destination_table_name = %s", |
There was a problem hiding this comment.
If the mirror is significantly behind, txids wrapping around wouldn't be unheard of (11 hours at 100K writes per second). Is there a way to deal with that (handle duplicates or stop sync until prev txid was cleaned up)?
🔄 Flaky Test DetectedAnalysis: TestPeerFlowE2ETestSuitePG_CH_Cluster/Test_Types_CH failed on a 1-microsecond QValueTime precision mismatch (17m38.020664s vs 17m38.020663s) between Postgres and ClickHouse, a value-dependent rounding flake rather than a logic bug. ✅ Automatically retrying the workflow |
No description provided.