Appending hostname to fetch error messages breaks is-network-error and p-retry packages

[AmirL]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

10.29.0

Framework Version

NextJs 15

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

The fetch instrumentation modifies network error messages by appending the hostname:

// packages/core/src/instrument/fetch.ts:106-123
error.message = `${error.message} (${url.host})`;
// "Failed to fetch" → "Failed to fetch (example.com)"

Expected Result

The Problem

Popular packages like is-network-error (2M+ downloads/week) and p-retry (6M+ downloads/week) rely on exact error message matching:

const errorMessages = new Set([
  'Failed to fetch',  // Exact match required
  'Load failed',
  'NetworkError when attempting to fetch resource.',
]);

When Sentry modifies the message to "Failed to fetch (example.com)", these packages no longer recognize it as a network error, causing:

• p-retry stops retrying network failures
• Legitimate transient errors fail permanently
• Breaking change with no migration path

Suggested Solutions

1. Add opt-out configuration: enhanceFetchErrors: false
2. Add hostname as an error property instead of modifying the message
3. Only modify the message in beforeSend, not the original error object

Actual Result

Additional Context

No response

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear]

JS-1281

[AmirL]

For reference, PR where it was added:
#15729