You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix: recover from dependency snapshot publication failures #295
In #288, clone support is probed only between two files inside the snapshot store, and admission compares only the checkout and store's device IDs. This does not verify that cloning works across the actual checkout/store path pair. Linux FICLONE reports EXDEV when the file descriptors are not on the same mounted filesystem; equal st_dev alone is not that guarantee. Reference: https://www.man7.org/linux/man-pages/man2/FICLONE.2const.html
After setup and readiness succeed, prepareInLock saves the checkout's success receipt before calling publishDependencySnapshot. A checkout-to-store clone failure then fails preparation and leaves the workspace quarantined, despite a usable installation. Once quarantine is cleared, the matching receipt causes later preparation to return reused without retrying publication, leaving the shared snapshot missing indefinitely.
Probe the actual checkout/store cloning relationship before setup and define consistent recovery when publication fails. Avoid writing final success evidence before all required preparation steps settle, or explicitly distinguish installation readiness from pending publication and retry the latter.
Add a cross-mount / clone-failure regression and assert receipt, quarantine, and subsequent retry behavior after a publication error.
Activity