asmhatreandClaude Sonnet 5.5
6d792f00e0
Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_017ic4b4VQVEJWetTT1dYzyJ
17 lines
1.3 KiB
Plaintext
17 lines
1.3 KiB
Plaintext
# Which layer retries what: counts taken from the provider's meter
|
|
|
|
(a) A transient DB failure on the write of chunk 2 (tickets 101-200), 300 tickets, Spring Batch write retry = 2
|
|
no failure status=COMPLETED billed calls=304 rollbacks=0
|
|
failure + Spring Batch retry status=COMPLETED billed calls=304 rollbacks=0
|
|
-> the write was retried inside the same transaction; the model was not asked again.
|
|
|
|
(b) The provider answers 429 to everything, 1 ticket. Calls the provider received for that ticket:
|
|
Resilience4j retry only (max 4 attempts) status=FAILED attempts=4
|
|
+ Spring Batch retry of the same exception (2) status=FAILED attempts=12
|
|
-> 4 x (1 + 2) = 12. Two retry layers on the same failure multiply, and each attempt also takes a limiter permit.
|
|
|
|
(c) A poison row at WRITE time (ticket 250): chunk 3 (201-300) rolls back and is scanned one item at a time.
|
|
processorNonTransactional (cached) status=COMPLETED billed calls=304 (no-failure baseline: 304) rollbacks=2 ledger rows=100 skipped=3
|
|
default (processor runs again per item) status=COMPLETED billed calls=403 (extra over baseline: 99) rollbacks=2 ledger rows=100 skipped=3
|
|
-> without processorNonTransactional(), every item of the failed chunk is classified a second time and paid for twice.
|