Consumer repositories can keep using Bun cache archives produced by the accumulating workflow after PR #262 lands because the exact cache key does not change. This delays cleanup of already-polluted archives and can reactivate one after a lockfile revert. It does not block PR #262 because the new workflow stops those archives from growing into a new lock generation, but a deliberate cache-generation policy would make future semantic cutovers immediate and predictable.
Background
GitHub Actions caches are immutable. A restore checks the primary key before any fallback key. PR #262 changes only restore-keys, so an archive already stored under bun-packages-<os>-<arch>-<lock-hash> remains an exact hit. The save step then skips because cache-hit is true.
Evidence
Before PR #262, main could publish an archive under the current exact key after restoring the previous lock's prefix snapshot. After the PR, a main run with the same lock still restores that archive. No clean archive can replace it under the same immutable key. Once the lock changes, the new exact-only path prevents further cache-to-cache carry-forward, so this is bounded legacy state rather than continued unbounded growth.
Concrete failure
A consumer merges PR #262 without a lockfile change. Its current polluted archive remains hot and is restored on every main run. A later lockfile revert can also select an older polluted archive if GitHub has not evicted it for inactivity.
Suggested verification
Add an explicit cache-schema generation to both the Bun primary key and its pull-request restore prefix. Seed the old generation under the current lock, then verify the first main run with the new generation misses the old archive and publishes a clean snapshot. Document when a cache-semantic change requires incrementing the generation.
Found while reviewing #262.
Consumer repositories can keep using Bun cache archives produced by the accumulating workflow after PR #262 lands because the exact cache key does not change. This delays cleanup of already-polluted archives and can reactivate one after a lockfile revert. It does not block PR #262 because the new workflow stops those archives from growing into a new lock generation, but a deliberate cache-generation policy would make future semantic cutovers immediate and predictable.
Background
GitHub Actions caches are immutable. A restore checks the primary key before any fallback key. PR #262 changes only
restore-keys, so an archive already stored underbun-packages-<os>-<arch>-<lock-hash>remains an exact hit. The save step then skips becausecache-hitistrue.Evidence
Before PR #262, main could publish an archive under the current exact key after restoring the previous lock's prefix snapshot. After the PR, a main run with the same lock still restores that archive. No clean archive can replace it under the same immutable key. Once the lock changes, the new exact-only path prevents further cache-to-cache carry-forward, so this is bounded legacy state rather than continued unbounded growth.
Concrete failure
A consumer merges PR #262 without a lockfile change. Its current polluted archive remains hot and is restored on every main run. A later lockfile revert can also select an older polluted archive if GitHub has not evicted it for inactivity.
Suggested verification
Add an explicit cache-schema generation to both the Bun primary key and its pull-request restore prefix. Seed the old generation under the current lock, then verify the first main run with the new generation misses the old archive and publishes a clean snapshot. Document when a cache-semantic change requires incrementing the generation.
Found while reviewing #262.