Problem
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.
Inherited Bugbot finding: https://github.com/ClickHouse/ai/pull/4172#discussion_r4165537178
Affected code: packages/code/src/environment-preparation.ts and packages/code/src/dependency-snapshots.ts.
Problem
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,
prepareInLocksaves the checkout's success receipt before callingpublishDependencySnapshot. 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 returnreusedwithout 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.
Inherited Bugbot finding: https://github.com/ClickHouse/ai/pull/4172#discussion_r4165537178
Affected code:
packages/code/src/environment-preparation.tsandpackages/code/src/dependency-snapshots.ts.