Repository navigation
Conversation
CopyObject stats the source object, then reads it with GetObject. A short-lived object (e.g. a container registry upload under _uploads/) can be deleted in between: the read fails with NoSuchKey, the task fails and is retried, and only the retry sees the object missing and skips it. Each such race shows up as a failed task in worker_failed_tasks_total. When reading or uploading the content fails, check whether the source object still exists and return dom.ErrNotFound if it does not, the same as when the first stat finds no object. Signed-off-by: Denis Ivanov <dendw.work@gmail.com>
den-dw
requested review from
aiivashchenko,
arttor,
fa-at-pulsit and
schucly
as code owners
October 27, 2026 08:18
Contributor
|
will be fixed in #285 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
CopyObjectstats the source object, then reads its content withGetObject. A short-lived object can be deleted in between. We see it all the time with a container registry (distribution) behind the proxy: blob uploads go to_uploads/<id>/dataand_uploads/<id>/hashstates/..., which the registry deletes seconds later.The read then fails with
NoSuchKey:The retry stats the object, finds nothing and skips it (
object sync: skip object sync: object missing in source). Nothing is lost, but every such race is counted inworker_failed_tasks_total, so an alert on that metric fires on a healthy replication.Fix
If reading or uploading the content fails,
CopyObjectstats the source object again. If the object is gone, it returnsdom.ErrNotFound, the same as when the first stat finds nothing, andobjectSyncskips the object without a retry. Other errors are returned as before.The second stat checks the source object directly: a
NoSuchKeyfromPutObjectalone doesn't tell whether reading the source or writing the destination failed.Testing
go build ./...,go vet ./service/worker/...,go test ./service/worker/....I didn't add an e2e test: the object would have to be deleted exactly between the stat and the read, and the e2e environment has no hook for that. We're rolling this change out in production on top of v0.7.10, where a GitLab container registry is replicated between two S3 providers.