{"version":"2.1.283","anchor":"dir-sync-store-full-no-longer-aborts-the-before-command-syn","canonical_anchor":"dir-sync-store-full-no-longer-aborts-the-before-command-syn","heading":"Directory sync treats a full store as non-blocking, and a full lane now counts as store_full","tier":"notice","area":"Cloud Sync","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/dir-sync-store-full-no-longer-aborts-the-before-command-syn","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Directory sync treats a full store as non-blocking, and a full lane now counts as `store_full`\n\nWhen directory sync's store is full, remote commands now run anyway instead of failing, and a full link lane is reported as store_full\n\n**Unclear.** What this means for the command itself or for what a user sees is not clear.\n\n**What**\n\nDirectory sync sends your session's file changes to another machine before a command runs there. When the store holding those changes is full (`store_full`):\n\n- The failure is still recorded, but the exchange with the other machine carries on. Before, any failed push stopped at that point.\n\n- The remote command now just runs, instead of failing with a message and a suggested fix.\n\n- `store_full` was added to the file-sync failure reasons.\n\nIn the git-based sync worker, a `lane_full` answer while detached now marks the store as full. Before, it went through the generic not-sent path and was counted as a failed upload. Bundles that are too large no longer take a separate early exit in that mode. A record rebuilt from an earlier stored row now carries its real `unshipped` flag instead of always false.\n\n**Why**\n\nA full sync store no longer blocks commands on the other machine. The catch is that such a command may run on files that are missing your latest changes, and you get no note saying so.\n\n- Area: Cloud Sync\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}