When multiple repository operations execute concurrently on shared pool
directories, race conditions could cause .deb files to be deleted despite
appearing in repository metadata, resulting in apt 404 errors.
Three distinct but related race conditions were identified and fixed:
1. Package addition vs publish race: When packages are added to a local
repository that is already published, the publish operation could read
stale package references before the add transaction commits. Fixed by
locking all published repositories that reference the local repo during
package addition.
2. Pool file deletion race: When multiple published repositories share the
same pool directory (same storage+prefix) and publish concurrently, cleanup
operations could delete each other's newly created files. The cleanup in
thread B would:
- Query database for referenced files (not seeing thread A's uncommitted files)
- Scan pool directory (seeing thread A's files)
- Delete thread A's files as "orphaned"
Fixed by implementing pool-sibling locking: acquire locks on ALL published
repositories sharing the same storage and prefix before publish/cleanup.
3. Concurrent cleanup on same prefix: Multiple distributions publishing to the
same prefix concurrently could have cleanup operations delete shared files.
Fixed by:
- Adding prefix-level locking to serialize cleanup operations
- Removing ref subtraction that incorrectly marked shared files as orphaned
- Forcing database reload before cleanup to see recent commits
The existing task system serializes operations based on resource locks,
preventing these race conditions when proper lock sets are acquired.
Test coverage includes concurrent publish scenarios that reliably reproduced
all three bugs before the fixes.
