The SDK tarball preflight asks for archive + margin before downloading. It does not account for a copy of the archive that is already in the cache.
install_tarball_runtime has no cache-hit check, so a re-run always re-downloads, and write_file_atomically writes a sibling temp file and then renames. During that window both the existing cached copy and the new one are on disk, so the true peak is archive + existing cached copy + margin while the preflight asks for only one of them.
This under-asks, so the consequence is a late failure rather than a false refusal — strictly the safer direction, and the out-of-space message is now mapped either way. It is still a real gap in the estimate.
Two ways forward, probably both: check for a usable cached artifact and skip the download entirely (engines/lemonade/src/lib.rs already implements that pattern), and include the size of any existing destination file in the requirement.
Split out of the review of #171 to keep that change to one concern.
The SDK tarball preflight asks for archive + margin before downloading. It does not account for a copy of the archive that is already in the cache.
install_tarball_runtimehas no cache-hit check, so a re-run always re-downloads, andwrite_file_atomicallywrites a sibling temp file and then renames. During that window both the existing cached copy and the new one are on disk, so the true peak is archive + existing cached copy + margin while the preflight asks for only one of them.This under-asks, so the consequence is a late failure rather than a false refusal — strictly the safer direction, and the out-of-space message is now mapped either way. It is still a real gap in the estimate.
Two ways forward, probably both: check for a usable cached artifact and skip the download entirely (
engines/lemonade/src/lib.rsalready implements that pattern), and include the size of any existing destination file in the requirement.Split out of the review of #171 to keep that change to one concern.