statusCodes does not properly limit which requests are retried

[Inrixia]

Describe the bug

Setting the statusCodes property on retry should ensure that only responses which match that code are retried. However I am seeing retries for statusCodes not specified.

• Node.js version: v19.0.0
• OS & version: Win11

Actual behavior

Non 429 responses are retried.

Expected behavior

Only 429 responses are retried

Code to reproduce

got.extend({
            retry: {
                limit: 5,
                calculateDelay: ({ attemptCount, error }) => {
                    // Retry after the number of seconds specified in the "retry-after" header
                    const retryAfter = error.response?.headers?.["retry-after"];
                    if (retryAfter !== undefined)
                        return parseInt(retryAfter) * 1000; // Convert to milliseconds
                    // Default retry delay
                    return 1000 * attemptCount;
                },
                statusCodes: [429], // Retry on 429 status code
            },
        })

Checklist

• [x] I have read the documentation.
• [x] I have tried my code with the latest version of Node.js and Got.

[Inrixia]

The limit variable also does not apply at all!

[cillen]

I have the same issue. My retry config: const retry = { retries: RETRY_ATTEMTS, calculateDelay: () => RETRY_DELAY, statusCodes: [102], errorCodes: ['ECONNRESET'], methods: ['POST'], }

I still get retries on 500 errors for example. Got version: 11.8.6 Node version: 18.12.1

[Inrixia]

The only fix for this so far is to check the status code in the function itself and return nothing (which does not retry) if it's not a code you want.

That's not to say this shouldn't be fixed though.

[cillen]

If you omit the calculateDelay in the retry config, the statusCodes limit works, but the retries limit stil does not apply. const retry = { retries: RETRY_ATTEMTS, // calculateDelay: () => RETRY_DELAY, statusCodes: [102], errorCodes: ['ECONNRESET'], methods: ['POST'], }

[cillen]

Any chance there will be a fix for this any time soon?

[Inrixia]

My original report of this is 3 months old so I'm very doubtful. For now ig just ignore the feature and manually implement it.

[cillen]

Ok bummer. It would have been neat to use the config instead of manually wrap the call. Well well..

[diVid3]

Same issue here, sigh.

[rolu01]

Is this issue addressed and fixed? Thanks!