[RUM] The instance-logout catch that exists to swallow a failure console.errors it straight into Error Tracking (34 events, 13 sessions, 30d)

[dawsontoth]

What RUM shows

Failed to log out from <entity-id>, carrying on is a standing family in Error Tracking:
34 events across 13 sessions in the 30 days to 2026-09-02, every one
source: console, handling: handled. It is not bursty — it lands on ten separate days,
including 4 on 2026-08-31 and 2 on 2026-09-01.

Split by the status the instance/cluster returned:

status	events
500	18
404	16

19 are cluster logouts, 15 are instance logouts.

Why it reaches Error Tracking

src/features/auth/store/authStore.ts:527, inside
signOutFromPotentiallyAuthenticatedInstances:

try {
	const instanceClient = getInstanceClient({ id: entityId });
	await onInstanceLogoutSubmit({ entityId, instanceClient });
} catch (err: unknown) {
	console.error(`Failed to log out from ${entityId}, carrying on`, err);
}

The catch exists to swallow the failure — the local credential state has already been
cleared above it and the sign-out proceeds regardless. But the RUM SDK instruments
console.error and reports it as a RUM error with error.source: "console", so the
one call whose job is to keep the failure out of the way is what puts it into Error
Tracking. This is the same trap #1658 documented for the Reo loader, where the fix was
console.debug (not collected by RUM, still visible in devtools) — see
src/integrations/reo/reo.ts, which now carries a comment saying exactly this.

shouldKeepEvent cannot help here: the message is Studio's own composed string, not a
connectivity-class Axios message, and the drop rules are deliberately narrow.

The judgement call this needs

Swapping console.error → console.debug is a one-line change with an established
precedent, but a failed logout is not purely cosmetic: the entity-side session may
still be valid server-side even though Studio has forgotten it locally. A 404 most
likely means the endpoint or entity is gone (nothing to invalidate); a 500 means the
instance was asked and failed, which is the case where the stale session is real.

Two defensible options:

1. console.debug for both — matches fix(reo): stop a blocked analytics script from reporting as a Studio error #1658, accepts that a failed remote logout is
   an expected state of an unreachable instance, and relies on the instance's own session
   expiry. Simplest, removes the whole family.
2. console.debug for 404, keep 500 visible — preserves the signal for the case
   where the instance answered and refused, at the cost of leaving ~18 events/30d in
   Error Tracking.

I did not pick one unilaterally because option 2 is a security-adjacent tradeoff rather
than a noise-reduction one.

Reproduction

Sign out of Studio while holding a potentially-authenticated session against an instance
that is down or has been deleted; the logout POST 404s or 500s, the catch fires, and a
RUM error appears with error.source: "console" and handling: handled.

Related

• fix(reo): stop a blocked analytics script from reporting as a Studio error #1658 — established that console.error in a noise-reduction catch is self-defeating,
  and that console.debug is the channel.
• [RUM] "AxiosError: Network Error" is never dropped — the endpoint gate needs a resource URL that console-sourced Axios errors never carry #1669, and the PR broadening the Axios timeout rule — same underlying theme (handled
  failures reaching Error Tracking through console.error), different mechanism.