Retry on spurious failures when caching built wheels

[zanieb]

#2419 appears to have only applied this retry to wheels that were already downloaded (though I would have to look more carefully to be certain). In #1491, we've gotten continued reports of spurious failures on Windows and tracing reveals that we are not applying our retry logic during the rename. I believe we're in this code path — switching to our backoff retry should resolve the failures.

[zanieb]

There are various other rename calls that we may want to audit as well. I've changed the remaining async ones in #4606, I don't see reason to change the synchronous ones unless we see problems?

[zanieb]

I believe this is only called at

uv/crates/uv-distribution/src/source/mod.rs

Line 1430 in f01aebe

.wheel(cache_shard)

when performing build_distribution i.e. placing a built wheel in the cache

The other pull request includes persist_archive which is called at

uv/crates/uv-distribution/src/source/mod.rs

Line 863 in f01aebe

.persist_archive(&resource.path, entry.path(), hashes)

i.e. extracting a source distribution to the cache

[zanieb]

Here's the error we're attempting to address

Caused by: Failed to write to the distribution cache
Caused by: failed to rename file from \?\C:\Users\gitlabwinrunner\AppData\Local\Temp.tmpanLS7H\built-wheels-v3.tmpc3E2Z7\pywinusb-0.4.2 to \?\C:\Users\gitlabwinrunner\AppData\Local\Temp.tmpanLS7H\built-wheels-v3\index\70e6dbc41e17fe7c\pywinusb\0.4.2\or1SrhePMDCdKnzdyzMki\pywinusb-0.4.2.zip

[axel-kah]

I took a guess and pulled the binary from this PRs build binary | windows job:
https://github.com/astral-sh/uv/actions/runs/9704735622/job/26785531647?pr=4605
https://github.com/astral-sh/uv/actions/runs/9704735622/artifacts/1646714270

When I use that in conjunction with hatch, then all I get is this 😬

$ hatch version
Setting up build environment for missing dependencies
Installing Python distribution: 3.11
thread 'main' has overflowed its stack

[zanieb]

@axel-kah The debug builds have a weirdly small stack size on Windows — not a problem in releases but we have to work around it during testing.

$Env:UV_STACK_SIZE = '2000000'

More details in our contributing guide

[axel-kah]

After setting the stack size the debug build works - but run's into the same error. I'll give #4606 a shot as well.

EDIT: and no instance of retrying in the verbose log.

[axel-kah]

Hm, neither this nor #4606 seem to eliminate this problem so far.

[zanieb]

That's surprising :(