Problem. TestDedupeDynamo_Unreachable (tests/integration/dedupe_dynamodb_test.go) depends on wall-clock timing and can fail under load. It makes five failing Reserve calls against http://127.0.0.1:1 and then expects the sixth to be short-circuited, because "five failures in a second open the breaker". When the five calls take longer than a second, the breaker never opens and the assertion at line 247 fails:
Error: "dedupe store unavailable: dynamodb put_item: operation error DynamoDB: PutItem, exceeded maximum number of attempts, 1, ... dial tcp 127.0.0.1:1: connect: connection refused" does not contain "short-circuited"
--- FAIL: TestDedupeDynamo_Unreachable (2.31s)
Evidence (measured).
- Seen once in a local
make ci on a busy machine. The tree was main plus files unrelated to dedupe.
- The test took 2.31 s, so the five failures spread over more than the one-second window.
- An immediate re-run on the same tree passed.
- Frequency on GitHub runners is unknown; no CI failure of it has been seen yet.
Context. The test runs with t.Parallel() alongside container-backed integration tests, so a refused-connection dial plus SDK retry setup can be slow when the host is loaded (inferred).
Related: #728 (another timing-sensitive integration test).
Problem.
TestDedupeDynamo_Unreachable(tests/integration/dedupe_dynamodb_test.go) depends on wall-clock timing and can fail under load. It makes five failingReservecalls againsthttp://127.0.0.1:1and then expects the sixth to be short-circuited, because "five failures in a second open the breaker". When the five calls take longer than a second, the breaker never opens and the assertion at line 247 fails:Evidence (measured).
make cion a busy machine. The tree wasmainplus files unrelated to dedupe.Context. The test runs with
t.Parallel()alongside container-backed integration tests, so a refused-connection dial plus SDK retry setup can be slow when the host is loaded (inferred).Related: #728 (another timing-sensitive integration test).