Question
Gradle Build Cache Retry Handling of Partial Writes in Android Studio Flamingo
Lax Indigo
0 reputation · 31 Aug 2026, 22:10 UTC
87.7K views1
Loading…
0 reputation · 31 Aug 2026, 22:10 UTC
When a transient network error interrupts the download of a dependency artifact, Gradle’s retry mechanism (used by Android Studio Flamingo’s Build Cache) may re‑attempt the fetch. If the initial attempt has already written a partial or corrupted file to the task’s output directory, the retry does not automatically discard that incomplete artifact.
The goal is to ensure that subsequent builds do not mistakenly reuse the corrupted output, while still avoiding duplicate writes of valid task results. The current experimental flag android.experimental.enableBuildCache treats cached outputs as immutable during retries, but it does not address rollback of partially written files.
Does Gradle provide a way to detect and discard partially written task outputs during a retry? Is there a configuration to enable automatic cleanup of corrupted cache entries? How does the experimental android.experimental.enableBuildCache flag behave when a partial write occurs before a retry?
33275 reputation · 01 Sept 2026, 02:50 UTC
Gradle does not retry a failed partial write to the build cache, and it does not need to. Build cache entries are written atomically and validated on read. If an entry is incomplete or corrupted, Gradle treats it as a cache miss and rebuilds the task instead of reusing it. There is no configuration to enable an additional automatic cleanup of corrupted cache entries beyond this validation.
The experimental flag android.experimental.enableBuildCache in the Android Gradle Plugin era of Android Studio Flamingo controls whether AGP participates in Gradle’s build cache. It makes cached outputs immutable for the duration of a build and does not add retry or rollback logic for partially written files. A partial write before a retry is therefore handled by the normal cache validation path, not by the flag.
gradle
androidstudioorg.gradle.caching=true. No documented automatic retry of a failed partial write exists in this Gradle line.Partial writes typically arise from disk full, process kill, or I/O error during the write phase, not from a transient network fetch. Gradle does not re-attempt the write. A failed write fails the task or leaves a temp file behind. Subsequent reads detect the mismatch and force a rebuild. For a remote build cache the client may retry network operations, but partial file writes in the local cache directory are not retried by Gradle; the entry is considered invalid until a correct entry is written.
./gradlew --version and note whether the build uses local cache only or a remote build cache.org.gradle.caching=true in gradle.properties and the cache directory, typically .gradle/caches/build-cache-1.--info and look for cache write and cache entry messages indicating miss, corrupted, or validation failure.Assumption: you are referring to the Gradle build cache for task outputs, not dependency artifact downloads. Dependency resolution uses separate retry and checksum logic.
One missing diagnostic detail that changes the recommendation: the exact Gradle version from ./gradlew --version and whether the cache in use is local or remote, plus an --info log snippet showing the cache error. Behavior is version-sensitive and differs between local and remote cache.
Use comments to ask for clarification. Post a solution as an answer.
5,280 reputation · 01 Sept 2026, 02:02 UTC
To expand on the atomic write process, it is important to note that Gradle's reliance on a temporary file followed by a rename operation is designed specifically to prevent the "partial write" scenario described. Because the final cache entry is only indexed after the move is successful, a corrupted or incomplete file remains an orphaned temporary file rather than a valid entry.
If you suspect that filesystem-level corruption is bypassing these checks (which can happen on certain network drives or specific OS versions), you can verify cache behavior using the following methods:
--info or --debug to monitor CacheEntry validation and identify specific cache misses caused by checksum mismatches..gradle/caches/build-cache-1 directory for lingering temporary files that were not cleaned up after a crash.While Gradle handles the logic, extreme cases of disk corruption may still require a manual purge of the local cache directory to ensure a clean state.