fix(QueryRunner): adjust retry logic to correctly account for maxRetries#782
Open
podrivo wants to merge 3 commits into
Open
fix(QueryRunner): adjust retry logic to correctly account for maxRetries#782podrivo wants to merge 3 commits into
podrivo wants to merge 3 commits into
Conversation
Updated the retry logic in QueryRunner to ensure that the total number of attempts includes the initial try. Changed the calculation of the number of retries to use the nullish coalescing operator (??) for better handling of explicit zero values. Updated related variable names for clarity.
…message format Added a note to the CHANGELOG explaining that `maxRetries` now represents the number of retries after the first attempt, and that `maxRetries: 0` allows for a single try. Updated the error message in QueryRunner to provide clearer information on the number of tries and ports involved.
Updated the description of the `maxRetries` parameter to specify that it represents the number of retries after the first attempt, with `0` allowing for a single try. This aligns with recent changes in the retry logic and enhances user understanding.
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
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.
Closes #640
Problem
In v5 the
maxAttemptsoption was renamed tomaxRetries, but the underlying logic was never changed — somaxRetriesstill meant "total number of tries." This caused the issues reported in #640:maxRetries: 1performed a single try, when the name implies one initial try plus one retry.maxRetries: 0was impossible. The value was read with||, so0fell back to the default of1. There was no way to request a single try with no retries.Failed all 3 attemptsatmaxRetries: 1mixed two concepts: each try runs every candidate port (query/game/cached), so "attempts" = tries × ports. This multiplication is intended (givenPortOnlyrestricts to one port), but the message gave no way to tell the two apart.Fix
maxRetriesas the number of retries after the first attempt (total tries per port =maxRetries + 1).??instead of||, so an explicit0is honored.tries x ports.Examples
Attempt counts (tries × candidate ports), measured by stubbing the per-attempt call to always fail:
Error message now:
Failed all 3 attempts (1 tries x 3 ports).Compatibility
noBreadthOrderordering are unchanged — only the number of tries changes.maxRetries: Nnow performsN + 1tries per port. This is the intended correction of the option's meaning, and is called out in the CHANGELOG. To get the old "exactly one try" behavior, passmaxRetries: 0(now possible), optionally withgivenPortOnly: trueto also skip extra ports.1, now meaning "try once, then retry once."Testing
npm run lint:check— no new errors (pre-existing errors in unrelatedprotocols/*.jsare untouched).noBreadthOrderordering with a local harness that stubs the attempt call (no live server needed).