Some other notes:

• I picked a token size of 16 because log2(64) * 16 = 96 bits of entropy, which I think is more than enough for our use cases (in the non-security-sensitive setting we could go even lower, but even in the security setting that's a comfortable guessing/collision margin).

Ah, looks like we do have a behavioral assumption around ArchiveId's format:

 thread 'tests::test_link_deserialize' (133698) panicked at crates/uv-cache/src/lib.rs:1455:9:
    assertion failed: Link::from_str("archive-v0/foo").is_ok()

(The assumption before was that any String can be an ID, but now we're strict about it being a uv_fastid::Id-formatted string.)

I think we have a few options here:

1. I could bump the CacheBucket for archives to archive-v1, which (IIUC) will prevent us from reading the old entries and failing.
2. I could change the Link::from_str tests to make them pass, under the assumption that we'll just silently ignore the now-invalid archive entries.
3. We could revert to ArchiveId(String) instead of ArchiveId(uv_fastid::Id), which loses us a few allocations but preserves exact compatibility with the current IDs.

Edit: This also might be minor in any case, since FWICT Link is basically dead code except one Windows path?

Do we need to be able to read existing IDs from disk? Like, do we need to be able to read these into our ID format?

❯ ls archive-v0
_3OAfZctF8UydglecrX0x aDcgovMVjxtaHXNCqt5MB gDOrNLlXb_61jOj8QHVNd mptS-Rhq4XPOyS7GFLAo7 TPYObcfx552jcjLbC-Ze_
_3oBciWusDv3wJMSA2k1j aDesp9jd9o_OfiZmqQt1Q ge4B5Av6_I1AmYM_SE2n4 MQKGCSwouTUcv-18fv2ic tQkdqY0-v4mSiexMnhgIx
_4Xo0kTSe9pOtzJmIwQe1 ADEwFc5XvSpW4F_n6w3cc gemQALx3mCH46z5DdJG_1 MQxWuQXNpwxkEP_WGVqOP TR-qz4iFLjPmqB2DAzRal
_5fR2nwdv0mukbpiURbo5 AdPGqIgQ6dIcqtVY6Ukzj GfC2kpPVxWjalEumO-FTc MrHj-Y-c1IwwVts8Q-hqj TRypPoYDSpSP9hE9nikNZ
_6uAgliFRctrSMvHkcgtw AdSANrr6dclYwxb5sUoI8 gfMBbzvHc6a0nY6rVDCI3 mRS75UNUPLwHMLfuHiYRL TS167myrBkRdHhfM2poMG
_7KPaIBs7gGkMZpCdkfUW AdwlJTA4HJmFauEKavD8S gfr7BTVGbqfWntoX9UXRM MRuSt3YdrkmMC8OkDWKGy tsiuXo_IEK4p57anWCKPE
_AWeEmMq3mrf8W_aPCcje AfyEl63gGYBZyravasAFW gGhXEwIaf4gbprwV0DtJr MS7FFdYzPtIw747AkAQO9 TSKa2juut_KuN-MDZLI_u
_CH8IEno0SZOFqwzSLX4d Ag_LijIN9aG30sSg2vQKS GgiV8fiNcZYdgMckklgnr MsfFoacczQ5Sycu6B6QvH tsnnqoFF-VkINtiDfdHnx
_cy8IlLQTNmkpj3XqHHjy ahMwCMSnw_FImlGvNWwIw GGqsuRRigeQW-Fj7uaAH4 MSZG2bqP04ghGHMaBUqIr TTBwEyhLXjmUHwIR_-eaj

I think if we bump the archive version then no, the old ones will just become orphaned (like other bucket bumps). But I'll test that tomorrow, since it looks like the archive bucket hasn't been bumped before.

Bumping the archive version is a breaking change though. Is that warranted here? Maybe we could do that as a separate step later?

Edit: the case I mainly have in mind is a read-only mounted uv cache, where it's undesirable/impossible for the uv process to refresh it (because e.g. it's network-isolated)

Bumping the archive version is a breaking change though. Is that warranted here? Maybe we could do that as a separate step later?

I might be missing it, but what makes it a breaking change? IIUC in the read-only cache case like that it'll result in cache misses rather than hard failures, but I don't think we typically consider that a breaking change (since we've done bumps with e.g. the metadata cache on patch releases).

With that said I agree it's not warranted here 😅 -- this is all a bit of a micro-optimization/attempt to save a few heap allocations on archive cache keys. I think the easiest thing for me to do here is to just revert back to using String for these keys and make a note that in the future we can re-roll the type + bucket version here.

Bumping the bucket isn't considered a breaking change.

It does seem reasonable to avoid bumping for now and to do it when we have a stronger motiviation.