You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at n1, we can see that a range was split immediately after a changfeed was created,
I240109 07:05:53.804169 5274 kv/kvserver/replica_command.go:440 ⋮ [T1,Vsystem,n1,split,s1,r67/1:‹/{Table/65-Max}›] 205 initiating a split of this range at key /Table/104 [r68] (span config)
Note that replication of system ranges is co-occurring with the changefeeds. It might be possible to exclude duplicates by waiting for replication to finish (see WaitFor3XReplication). Given the current implementation of this test, we would then expect no other range splits. Otherwise, if duplicates cannot be provably excluded, then the assertion should be weakened.
@andyyang890 - wdyt about just updating the testing logic in here to eliminate dupes? It's expected that we will be encountering them on a changefeed. This should be a pretty easy fix.
This came up during an adhoc run in AWS using graviton3 instances,
We can see that some events were duplicated whereas the test assertion expects uniques.
cdc_filtering_logs.tar.gz
Jira issue: CRDB-35256
Epic CRDB-13169
The text was updated successfully, but these errors were encountered: