{"version":"2.1.248","anchor":"sync-failures-distinguish-lane-unavailable-from-unsupported","canonical_anchor":"sync-failures-distinguish-lane-unavailable-from-unsupported","heading":"Sync failures distinguish \"lane unavailable\" from \"unsupported\"","tier":"notice","area":"Cloud Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/sync-failures-distinguish-lane-unavailable-from-unsupported","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Sync failures distinguish \"lane unavailable\" from \"unsupported\"\n\nSync errors now distinguish a server declining this path from one with no sync at all.\n\n**What**\n\nSession sync errors are classified more precisely, so a server that is declining this particular sync path is no longer reported the same as a server that does not support sync at all. Applies to everyone, no gate.\n\n**Details**\n\n- HTTP 400 with a `laneDenied` reason becomes `lane_unavailable`.\n- HTTP 400 for upload or download unavailable becomes `lane_unavailable` with cause `direct_sync_off`.\n- 501 and 405 remain `unsupported` and now carry the status code.\n- 404 counts as `not_found` only outside the `begin` phase and only when the body is a not-found error.\n\n**Evidence**\n\n`{ kind: \"lane_unavailable\", cause: \"direct_sync_off\" }`\n\n- Area: Cloud Sessions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}