Allow http request retries on all commands

[alfredoUcar]

Context:

I'm having non persisten errors during next.js builds due to connectivity problems that cause inherit http requests of releases new/finalize commands fail.

Since SENTRY_HTTP_MAX_RETRIES only aplies to file related commands I'm forced to retry the entire build process even if previous steps succeed.

Feature request

To improve performance and prevent retries at higher levels (such as ci/cd job) it would be great to either extend SENTRY_HTTP_MAX_RETRIES to all requests or support new segmented variables like SENTRY_HTTP_MAX_RETRIES_{KIND}

[szokeasaurusrex]

@alfredoUcar Thanks for the feedback, this is something we can certainly look into adding

[szokeasaurusrex]

@alfredoUcar, quick clarification on this point:

Since SENTRY_HTTP_MAX_RETRIES only aplies to file related commands I'm forced to retry the entire build process even if previous steps succeed.

Why would you need to retry the entire build process if one of the commands fails? Couldn't you just retry the one command that failed?

[alfredoUcar]

Because the error occurs within a command that is difficult to break down in a way that allows retrying only the failing part. Here’s some additional context:

The issue happens in a CI/CD pipeline with two main stages:

• Build image ← the error happens here
• Deploy image

The stack trace looks something like this:

• docker build (CI/CD job)
• RUN npm run build (Dockerfile)
• next build (Next.js command)
• Error: could not resolve hostname (sentry9..net)

When this error occurs, I have to rerun the entire pipeline.

I have already implemented a retry policy at the CI/CD job level, but this means rerunning Dockerfile steps that had previously succeeded. Even with Docker caching, this adds unnecessary extra execution time.

A possible alternative is implementing retries specifically for npm run build inside the Dockerfile (which is an alias for next build). However, this approach adds complexity and is still inefficient because next build would have to run from scratch each time—when in reality, only part of the build process is failing. Since next build is the real bottleneck, this wouldn’t significantly improve the situation.

If next build had a built-in retry mechanism that could detect and retry only the steps failing due to temporary connectivity issues with Sentry’s API, the build process could resume from that point instead of restarting entirely