Retry as many times as retries says - #23
Merged
Merged
Conversation
…are not logged A 401 is retried like a server error, and neither the status of a failed response nor a dropped batch shows up in NLog's internal log. The 408 and 429 cases pass already and pin that those stay retried. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every non-success response now writes its status and reason phrase to NLog's internal log. Only responses worth another attempt are retried: no response, 408, 429 and 5xx. Any other status drops the batch right away with an error, which for 401 and 403 hints at the source token and the endpoint. A batch that runs out of retries is no longer dropped silently either. Based on the status code handling in #7. Co-authored-by: Rolf Kristensen <11509660+snakefoot@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
retries="0" sends nothing at all and retries="1" makes a single attempt. The two tests that ran a batch out of retries pinned that count and now expect one retry after the first attempt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The first attempt always happens, then up to `retries` retries with the same back-off. retries="0" sends every batch once instead of dropping it unsent, and the error line reports the real number of attempts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PetrHeinz
marked this pull request as ready for review
September 30, 2026 14:56
This was referenced Sep 30, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#25 is stacked on this PR, so the order is #20, this PR, then #25.
retriescounts attempts, not retries:Client.Sendrunsfor (i = 0; i < retries; ++i), so the defaultretries="10"makes ten attempts, andretries="0"never sends anything and drops every batch without a word. The doc comment of the property and the example README call it the number of retries.retriesretries with the same back-off as before: 1 second before the first retry, 2 before the second, and so on.retries="0"sends every batch once and never retries it.Retriesand the example README say that it counts retries after the first attempt. The publicClientconstructor'sretriesparameter changes its meaning the same way.KeepsDeliveringAfterBatchRanOutOfRetriesandLogsTheBatchDroppedAfterRetriespinned the old count (Retries = 1was a single attempt): they now answer two 500s, expect both attempts, and the error line says 2 failed attempts. Two new tests pin the count:Retries = 0gets exactly one request,Retries = 2gets exactly three with the same body, and in both the next log is still delivered.The first commit adds the tests and is expected to be red: with
Retries = 0nothing is sent at all, and the other three wait in vain for the last attempt. The second commit changes the loop.🤖 Generated with Claude Code