mirror of
https://github.com/aptly-dev/aptly.git
synced 2026-05-31 04:30:44 +00:00
André Roth
9e91ee4c4a
Affected endpoints: apiPublishRepoOrSnapshot (POST /api/publish/{prefix}),
apiPublishDrop (DELETE /api/publish/{prefix}/{distribution}).
Both handlers used the outer-scoped collectionFactory and collection
variables inside the task closure. These were captured before the task
lock was acquired, so under concurrent load each task operated on a
stale DB view:
apiPublishRepoOrSnapshot: snapshot/localRepo LoadComplete,
NewPublishedRepo, CheckDuplicate, Publish, and collection.Add all
used the pre-lock collectionFactory/collection. Two concurrent
POST to same prefix could both pass CheckDuplicate (neither sees
the other in the stale DB view) and race on disk writes.
apiPublishDrop: collection.Remove used pre-lock collection,
potentially racing with concurrent updates/other drops.
Fix: inside the task closure create a fresh taskCollectionFactory and
taskCollection. All DB reads (LoadComplete) and writes
(CheckDuplicate, Add, Remove, Publish) now run against the authoritative
DB state after the lock is held.