{"version":"2.1.257","anchor":"new-network-is-off-artifact-fetch-error-state","canonical_anchor":"new-network-is-off-artifact-fetch-error-state","heading":"New \"network is off\" artifact-fetch error state","tier":"notice","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257\/e\/new-network-is-off-artifact-fetch-error-state","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257","markdown":"### New \"network is off\" artifact-fetch error state\n\nArtifact fetches now report when your org's network access is off and that retrying will not help.\n\nArtifact and asset fetches now detect a specific 403 response body indicating that a cloud session's org network access is off, distinct from network access merely being unavailable. This case is reported as a `network_off` result with a message stating that retrying from here will not help, rather than falling through to the generic relay-unavailable error path.\n\nThe artifact tool also now gives distinct explanatory messages when reads or writes fail because the cloud session lacks network access versus because database access isn't available in the current cloud session, so the model can tell the failure kinds apart instead of blindly retrying. Underlying database read\/write requests check a `network-off` gateway policy and return a refused-with-reason response (`network_off` \/ `whoami_network_off`) ahead of other checks when networking is disabled, and the fetch path itself recognizes an exact-match set of two policy-denial strings in the 403 body to trigger this handling.\n\n- Area: Artifacts\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}