[RUM] "AxiosError: Network Error" is never dropped — the endpoint gate needs a resource URL that console-sourced Axios errors never carry

[dawsontoth]

Summary

shouldKeepEvent drops "other network failures" only when it can attribute them to an
instance/cluster operation endpoint via error.resource.url. Every
AxiosError: Network Error that actually reaches Error Tracking arrives without that
field, so the gate has never fired for a single one of them. It is the same
URL-attribution blind spot that #1371 fixed for timeouts — the fix was applied to the
timeout branch directly above and never to this one.

86 events / 24 sessions in the last 7 days; 553 events / 121 sessions in 30 days. With the
browser-extension family from #1645 now filtered, this is the largest remaining error
family in Studio's Error Tracking.

Surfaced by the daily automated RUM review (RUM app f590deee-…, env:prod).

Evidence

All 86 AxiosError: Network Error events in the last 7 days, grouped:

86  source=console   error.resource.url=absent   handling=handled

100% — no exceptions. Their handling stacks are React Query's global onError calling
console.error, which the RUM SDK instruments as an error with error.source: "console".
A console-sourced error is not a tracked resource, so it carries no
error.resource.url, so isInstanceEndpoint is always false.

Spread across views (7d): instance table browser 21, scaling 12, apps 11, cluster overview
10, finish-setup 7, and a tail across org/database/sign-in.

The asymmetry, in the file

src/integrations/datadog/shouldKeepEvent.ts — the timeout branch already states the
reason this pattern doesn't work:

// A request timeout is a connectivity-class failure, never a Studio bug: …
// Unlike the network failures below we drop these unconditionally, because the handled
// AxiosErrors that flood Error Tracking carry no resource URL to attribute them
// to an endpoint. …
if (/timeout of \d+ms exceeded/i.test(message)) {
    return false;
}

and then, further down:

const isNetworkFailure = /Network Error/i.test(message) || source === 'network';
if (isInstanceEndpoint && isNetworkFailure) {
    return false;
}

The comment on the timeout branch is correct and the measurement above confirms it applies
verbatim to network failures: for the events that actually flood Error Tracking, the
isInstanceEndpoint half can never be true. The 5\d\d branch immediately above has the
same shape and the same question hanging over it (all 10 500 events in 7 days are also source=console with no resource URL).

The open question, which is why this is an issue and not a PR

The obvious edit — drop isInstanceEndpoint from the network-failure condition, matching
the timeout branch — makes more connectivity failure invisible, and #1635 is an open
issue arguing that this class being invisible is itself the problem ("Connectivity-class
failures are deliberately invisible in Error Tracking, so @type:error alone
under-reports"). Those two pull in opposite directions and the resolution is a call for
whoever owns the observability story, not something to quietly land:

• Suppress — make the network-failure drop unconditional like timeouts. Error Tracking
  gets quiet; first-party reachability is then measurable only via
  @type:resource @resource.status_code:0, which is where [RUM] Direct-to-instance :9925 connectivity failures at 3.4× baseline (19 sessions, 11 orgs) — and the whole class is invisible in Error Tracking by design #1635 already says it has to be
  measured anyway.
• Keep and attribute — leave the events in, but give them an endpoint. The
  console.error in React Query's global handler is the only reason these have no URL;
  attaching the failing request's URL to the reported error would make the existing
  endpoint gate work as written and preserve the signal for non-instance hosts.

Either way, the current code is not doing what its comment says it does, and shouldn't be
left in that state.

Also worth noting while touching this file

console.error is what puts these in RUM at all — the RUM SDK instruments it directly
(no datadogLogs init required, and Studio has none). Any catch block whose purpose is to
keep an expected failure out of Error Tracking must not console.error; console.debug is
not collected and is the right channel for devtools-only visibility. Recorded here because
generic review advice ("don't swallow it, log it") is actively wrong in this file.