Best practices regarding third-party network errors on iOS

[PSniezak]

Hey there!

Since we added the Datadog SDK and enabled trackResources and firstPartyHosts (for our internal hosts only), our real errors have been buried under the iOS URLSession instrumentation. As an example, we use @rnmapbox/maps which cancels in-flight requests when the user pan/zoom on the map. These are harmless but account for 90% of our errors if we also count the rest of this iOS instrumentation with them.

I would like to clarify that these are session's resource errors, not errors from error tracking. The error.source_type is ios and error.type is mostly NSURLErrorDomain - -999, neither the errorEventMapper nor the resourceEventMapper sees them. So, for my question:

Is there a supported config to drop non-first-party network events, or to scope auto-instrumentation to firstPartyHosts only? It may be related to #774.

Happy to share more details if useful, thanks!

Edit 1 (23/06/2026):

• it's not possible to completely exclude these errors as of now, it's being audited by the contributors (see Best practices regarding third-party network errors on iOS #1311 (comment))
• if you're looking for ways to reduce/hide these errors for now, see Best practices regarding third-party network errors on iOS #1311 (comment) and Best practices regarding third-party network errors on iOS #1311 (comment)

[krotname]

From the current RN wrapper, I do not think there is a supported config that means “collect resources only for firstPartyHosts”.

Two separate things are happening:

• trackResources starts the JS resource tracking path.
• firstPartyHosts is used for distributed tracing / header propagation. On iOS it is passed into RUM.Configuration.URLSessionTracking(firstPartyHostsTracing: ...); it is not exposed as a host allow-list for resource collection.

That also explains why your JS resourceEventMapper does not see those events. The TS resourceEventMapper is registered through DdRum.registerResourceEventMapper(...) for the JS RUM resource path. Native iOS URLSession resources go through the native RUM configuration instead. In the Swift code, the native resourceEventMapper only drops resources marked with the internal _dd.resource.drop_resource attribute, and the wrapper only sets that marker for internally tracked duplicate requests.

So today the practical options look like:

1. Keep tracking enabled and filter these out in Datadog queries/monitors, for example by error.source_type:ios, error.type:NSURLErrorDomain, and code -999 / cancelled requests.
2. Avoid enabling the native URLSession path if the third-party native SDK traffic is too noisy for the app.
3. Open a feature request for the RN SDK to expose a native iOS resource predicate / mapper, or a “track only first-party URLSession resources” option.

For this specific Mapbox case, I would treat NSURLErrorDomain -999 as expected cancellation noise rather than an application error. But I do not see a current RN SDK switch that drops only those native iOS URLSession resource errors before ingestion.

[sbarrio]

Hi @PSniezak and @krotname, thanks for reaching out.

Indeed this is a known gap in the current implementation. With the introduction of the automatic NSURL request tracking by dd-sdk-ios we have been thinking on ways to properly allow RN users to configure, disable or modify it safely and easily from React Native.

The easiest and cleanest approach for now is to expose a toggle to disable the native tracking, but that may be too extreme and can negate the benefits of the automatic tracking on many fronts (such as tracking images rendered and loaded with FastImage, for example).

Exposing a specific mapper just to be run at the native level is another option, but we have not yet discussed how exactly would that look.

We'll be having an internal discussion about potential ways to improve it this week. We'll come back to you as soon as we have more details on the proposed solution.

Thanks for your support 🙇

[PSniezak]

Hi @krotname and @sbarrio, thanks to both of you for the quick and documented replies 🙏

@krotname, we did go with something quite similar to your first recommendation: for now, we are using the retention filters to filter out sessions containing these errors (@error.source_type:ios AND @error.type:"NSURLErrorDomain - -999" AND @error.resource.url_host:api.mapbox.com).

It is not perfect as a session with another error would still show these iOS specific errors, but it does filter out the vast majority of them. It also means that we can't really use the errors specific metrics for now, as they're computed on all of the ingested sessions.

@sbarrio, it's great to here thanks a lot. I do agree that an on/off toggle would be too agressive.

I'm leaving this discussion open if that's okay and will edit my main comment to reference both of you.

Thanks again!

[sbarrio]

Thanks @PSniezak 🙇

As a small update on this, we just had a discussion about the problem today and I was informed that there is a planned piece of work to streamline how the RN SDK exposes configuration for the native network request tracking. The proposed solution will probably involve a kind of allow list with reg-exp support so users are able to limit the resources being tracked (and for which errors are tracked). I don't have more details at this time but work will be tackled on Q3, so hopefully you don't have to wait too long 🙂