mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-06 05:17:42 +00:00
houseme
47c5a3ab35
A single PUT can enqueue the same object for transition twice — immediately (enqueue_transition_after_write) and again from the startup/lifecycle compensation backfill. transition_object's own namespace lock is commented out, so the two attempts are not serialized as same-object work: the winner transitions the object and removes its local data, and the loser then reads that already-removed data via get_object_fileinfo(read_data = true) and logs a spurious "get_object_with_fileinfo err ... No such file" / lifecycle_tier_operation_failed. For a large (multipart) object both attempts can also race the source read, corrupting the transferred copy. Guard the transition queue with an in-flight set keyed by (bucket, object, version). queue_transition_task claims the key before sending; a duplicate enqueue is reported handled without queueing a second task. The worker releases the claim once the transition finishes, so a later lifecycle pass can still re-transition the object, and a failed enqueue releases it immediately. This is the sole path into the transition channel, so every enqueue is covered. Surfaced while validating the >128 MiB transition fix end-to-end in Docker (rustfs/rustfs#4811); tracked as its own defect since it is unrelated to the checksum/multipart-client bugs. Tests: same-version enqueues dedupe (direct reserve and via queue_transition_task with spare capacity), a distinct object still hits the full-queue path, and a released claim can be re-acquired. Refs: rustfs/backlog#1268 Co-authored-by: heihutu <heihutu@gmail.com>