{"version":"2.1.265","anchor":"artifact-durable-subscribe-now-short-circuits-when-the-relay","canonical_anchor":"artifact-durable-subscribe-now-short-circuits-when-the-relay","heading":"Artifact relay subscribe\/unsubscribe now distinguish 'relay unavailable' from other refusals","tier":"notice","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/artifact-durable-subscribe-now-short-circuits-when-the-relay","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Artifact relay subscribe\/unsubscribe now distinguish 'relay unavailable' from other refusals\n\nWake subscriptions and live artifact frames now report distinctly when the relay itself is down or unsupported, versus other refusals\n\n**What**\n\n- Subscribing to artifact updates now returns early with `{outcome: 'skipped', reason: 'relay_not_served'}` when the session's relay isn't served at all.\n\n- Two new refusal reasons cover why a wake subscription couldn't register: `relay_not_served` (the cloud session can't register wake subscriptions at all) and `relay_unavailable` (the session's gateway refused to carry the subscription, commonly because the organization doesn't have it enabled).\n\n- Unsubscribing from a live artifact frame now also reports a `relay-unavailable`\/`relay-not-served` refusal distinctly (capturing the HTTP status or a \"relay down\" flag), tracked via a new `unwatch_relay_unavailable` telemetry event instead of being lumped into the generic `unwatch_client_policy` event.\n\n**Why** Previously these relay-down situations were reported the same as an ordinary access refusal (`subscribe_forbidden`\/`unwatch_client_policy`), making it hard to tell \"you're not allowed\" apart from \"the relay infrastructure isn't available.\" Separating the reasons should make it clearer when a problem is on the user\/org side versus an infrastructure limitation.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}