Groene AIandClaude Opus 5.5 18c899494f Wait for the replication queue in test_replication_after_partition ...

The test partitions node1 and node2 on the interserver port with
`iptables -j DROP` 10 times while inserting 100 rows. A node2 part fetch
that reuses a pooled keep-alive connection sends its request into the
DROP and waits on TCP retransmission backoff (cumulative ~6.2, 12.6,
25.4 s from a 200 ms RTO), so it can complete up to ~13 s after the last
heal, inside the 30 s fetch receive timeout. GET_PART entries for the
covering merged parts wait behind it, so one stalled fetch hides dozens
of rows. The old `assert_eq_with_retry` polled for only ~11.3 s after
the heal (20 x 0.5 s), which made the test fail with '100' != '48' on
master (Integration tests (arm_binary, 2/4), b4901fe6ac): in that
job's node2 system.part_log six fetches took 6.4-26.5 s, all with
HTTPConnectionsReused = 1, and the last one finished 0.5 s after the
last poll.

Run SYSTEM SYNC REPLICA on node2 (it pulls the log and waits for every
entry, including all 100 GET_PART entries) with a 120 s client timeout,
then assert the exact count.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-18 01:41:50 +00:00

..

configs

…

__init__.py

…

test_change_ip.py

…

test.py

Wait for the replication queue in test_replication_after_partition

2026-10-18 01:41:50 +00:00