Fix mutable path refresh: default mutable_ttl, revalidate after expiry #151
Reference in New Issue
Block a user
Delete Branch "benvin/mutable-refresh"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A remote created through the API without
mutable_ttlwas stored as 0, so its mutable paths never refreshed. Withcheck_mutable, the ETag expired together with the freshness key, so an expired mutable path was always refetched in full and never revalidated.mutable_ttlto 3600 on create; keep the stored value on update; explicit 0 still means never expiremax(10 × mutable_ttl, 7d), re-armed on each 304, only whencheck_mutableis set andmutable_ttlis non-zeroSetETag(..., 0)writes a never-expiringetag:<remote>:<path>key for every mutable path of every remote, includingcheck_mutable=falseremotes that never read it; nothing expires or GCs it, so keys for paths never requested again leak forever → write it only whenremote.CheckMutable, with a bounded TTL (e.g. a multiple ofmutable_ttlor a fixed 7-30d cap) instead of 0.delnever clears Redis, so the now-permanentetag:*keys survive remote deletion (and a same-name re-create can 304 against a stale ETag) → callh.cache.FlushRemote(ctx, name)afterDeleteRemote, with a test.stale_on_errorwith a failing HEAD, or etag cleanup on remote delete → add them.time.Sleep(1100ms)waits slow the suite and can flake under-race→ expire the freshness key viatestCache.SetTTL(..., time.Millisecond).No findings.