Fix flaky retry test in webhook-based-order-fill-notifications
The two "retry" deliveries in test_position_is_correct_across_retries_replays_and_reordering were built as fresh fill() calls, and fill() stamps time.time() on every call. That made each retry a different payload, so the consumer correctly flagged it DUPLICATE_CONTENT_MISMATCH and needs_reconcile came out 3 instead of 1. Windows' ~15ms clock granularity returns the same time.time() for both calls, so the digests matched and the test passed locally while failing on the Linux CI runner. Reuse the original payload objects, which is what an at-least-once redelivery actually is: the same bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
eb7108c285
commit
bfa202c9f1
@@ -585,12 +585,17 @@ class LedgerIntegrationTests(unittest.TestCase):
|
||||
mgr = WebhookConsumerManager()
|
||||
position = 0.0
|
||||
|
||||
# A retry is the *same bytes* redelivered, so the retried entries reuse
|
||||
# the original payload object. Rebuilding one with fill() would restamp
|
||||
# its timestamp and make the redelivery a content mismatch instead.
|
||||
e1 = fill(order_id="ORD_L", exec_id="E1", qty=30.0, sequence_num=1)
|
||||
e3 = fill(order_id="ORD_L", exec_id="E3", qty=40.0, sequence_num=3)
|
||||
deliveries = [
|
||||
fill(order_id="ORD_L", exec_id="E1", qty=30.0, sequence_num=1),
|
||||
fill(order_id="ORD_L", exec_id="E1", qty=30.0, sequence_num=1), # retry
|
||||
fill(order_id="ORD_L", exec_id="E3", qty=40.0, sequence_num=3),
|
||||
e1,
|
||||
e1, # retry
|
||||
e3,
|
||||
fill(order_id="ORD_L", exec_id="E2", qty=30.0, sequence_num=2), # late
|
||||
fill(order_id="ORD_L", exec_id="E3", qty=40.0, sequence_num=3), # retry
|
||||
e3, # retry
|
||||
]
|
||||
stale = fill(order_id="ORD_L", exec_id="E4", qty=999.0, ts=time.time() - 7200)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user