Proposal: Set a default limit for errorRetryCount

[ryohiy]

Hi,
I'd like to propose setting a default limit for errorRetryCount.

Background

It is generally recommended to set a maximum number of retries for error handling.
Reference: Google Cloud - Retry Strategy
Unlimited retries can cause the following issues:

• Continuous unnecessary traffic when a server is down for an extended period
• Potentially hindering server recovery

Proposal

I propose setting a default limit (e.g. 5) for errorRetryCount.

Question

Is there a specific reason or design philosophy behind the current unlimited retry behavior?
If this change is acceptable, I'd be happy to create a PR.

[manimovassagh]

Strong +1 on this. The unlimited retry default has bitten us in production more than once.

When a backend goes down, every open tab with SWR hooks turns into a retry machine. If you have 10 hooks per page across thousands of users, that is a significant amount of traffic hitting an already struggling service. It actively works against recovery.

We set errorRetryCount: 3 globally on day one of every new project now:

<SWRConfig value={{ errorRetryCount: 3 }}>
  {children}
</SWRConfig>

A default of 5 (as you proposed) would be reasonable. Even 3 would be fine. The exponential backoff helps, but without a cap, it just keeps going.

I do not think there is a deep design philosophy behind the current behavior — it is more of a safe default for simple demos where infinite retries means the data eventually shows up. But for anything beyond a toy app, you need a cap.

Would be happy to see this PR if the maintainers are open to it.