mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-06 12:09:12 +00:00
6c37ebb951
A source-side DELETE ?versionId=<marker> replicates as a version purge, and replicate_delete_to_target addressed it by the SOURCE marker id on every target. A generic S3 target answers a DELETE of an unknown versionId with 204 and keeps its marker, so the purge reported success and the marker stayed; the same event also spawned a second delayed-purge watcher that journaled a duplicate intent. Real VMs (R6.1 in backlog#2080) failed on the persisted-id fix alone because this path never consulted the mapping. Resolve the target version through the recorded mapping for marker purges (a corrupt record refuses, as the watcher does; nothing recorded keeps the source-derived id for id-mirroring peers), and do not spawn the delayed watcher for a version purge — that purge is the replication itself and its failures reach the journal as a purge entry.