gsadmin/rustfs
1
0
Fork 0
mirror of https://github.com/rustfs/rustfs.git synced 2026-09-02 02:08:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(s3): round-trip null-version delete-marker identity (#6765)

Browse Source 
* fix(s3): round-trip null-version delete-marker identity through listing and delete responses

On a versioning-suspended bucket, a null delete marker's identity was lost on the way back to the client at three points (issue #6745): ListObjectVersions advertised the marker's VersionId as the literal nil UUID instead of null; deleting by that id succeeded but the DeleteObjects/DeleteObject response reported the identity as null with no way to correlate it to the request; and the response lacked DeleteMarker/DeleteMarkerVersionId because the marker-ness comparison mixed the client-facing identity (Some(nil)) with the storage identity (None), so the removal also mis-recorded accounting and fired DeleteMarkerCreated semantics on later paths.

- Listing (bucket_usecase, s3_api/bucket, build_list_versions_next_marker) now maps the synthesized nil UUID to the literal null everywhere it reaches the wire, and VersionMarker::parse folds a nil-UUID marker from older listings into VersionMarker::Null so pagination resumes correctly.
- delete_objects normalizes both sides of the marker-ness comparison via delete_file_info_version_id (matching the adjacent explicit_delete_marker admission check) and reports DeleteMarkerVersionId as null for an explicit null-marker removal.
- resolve_delete_version_state reports delete_marker for an explicit-version delete whose target is a delete marker even when the bucket is versioning-suspended, fixing x-amz-delete-marker on the single-object path.
- The DeleteObjects response entry echoes the version identity the request addressed for marker removals, marker-removal accounting no longer records a marker creation, and notification events fire DeleteMarkerCreated only for actual marker creation.

Fixes #6745

* fix(s3): keep null-marker removal write shape undeleted and report marker semantics response-side

The first cut marked the storage delete request deleted for a null-marker removal, which FileMeta::delete_version interprets as the suspended-bucket delete-mints-a-marker write and re-creates the marker just removed. Carry marker-ness to responses via explicit_delete_removed_marker (single path) and a response-only branch flag (batch path) instead, keeping every storage write shape byte-identical to the pre-fix behavior. Adds an embedded end-to-end regression test covering the full issue #6745 round trip.
This commit is contained in:
Zhengchao An
2026-08-28 07:55:05 +08:00
committed by GitHub
parent db57fabcbd
commit 3c89c71f66
8 changed files with 449 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
crates/ecstore/src/set_disk/ops/object.rs
+44 -11
View File
@@ -42,12 +42,13 @@ use super::super::{
can_try_inline_data_shards_direct, check_object_lock_delete, check_object_lock_for_deletion_with_state,
check_object_lock_retention_update, classify_get_codec_streaming_object_class, classify_put_write_path,
classify_storage_error, collect_inline_data_shard_fileinfos_by_index, contains_key_str, create_bitrot_writer, debug,
delete_file_info_version_id, disk, ensure_delete_commit_locks_held, error, finish_set_disk_read_lock,
get_codec_streaming_reader_gate, get_object_body_cache_hook, get_raw_etag, get_small_object_direct_memory_decision,
get_stage_timer_if_enabled, get_str, get_transitioned_object_reader_with_tier_manager, inline_erasure_shard_file_offset,
inline_erasure_shard_size, insert_str, is_deadlock_detection_enabled, is_err_object_not_found, is_err_version_not_found,
is_explicit_null_version, is_lock_optimization_enabled, issue3031_diag_enabled, join_all, known_put_object_storage_size,
path_join_buf, put_restore_opts, record_compression_total_memory, record_get_codec_streaming_gate_decision,
delete_file_info_version_id, disk, ensure_delete_commit_locks_held, error, explicit_delete_removed_marker,
finish_set_disk_read_lock, get_codec_streaming_reader_gate, get_object_body_cache_hook, get_raw_etag,
get_small_object_direct_memory_decision, get_stage_timer_if_enabled, get_str,
get_transitioned_object_reader_with_tier_manager, inline_erasure_shard_file_offset, inline_erasure_shard_size, insert_str,
is_deadlock_detection_enabled, is_err_object_not_found, is_err_version_not_found, is_explicit_null_version,
is_lock_optimization_enabled, issue3031_diag_enabled, join_all, known_put_object_storage_size, path_join_buf,
put_restore_opts, record_compression_total_memory, record_get_codec_streaming_gate_decision,
record_get_direct_memory_decision, record_get_object_pipeline_failure, record_get_object_pipeline_failure_for_path,
record_get_object_reader_path_observation, record_get_stage_duration_if_enabled, record_lock_acquire,
reduce_write_quorum_errs, release_materialized_read_lock, replication_write_may_pass_worm_gate, require_restore_operation_id,
@@ -6521,7 +6522,21 @@ impl crate::storage_api_contracts::object::ObjectOperations for SetDisks {
}
}
if goi.delete_marker && dobj.version_id.is_some() && goi.version_id == version_id {
// Same normalization as `explicit_delete_marker` above: `goi.version_id`
// is the client-facing identity (`Some(Uuid::nil())` for a null
// version) while `version_id` is the storage identity (`None` for an
// explicit null). Comparing them raw made a null delete marker's
// removal take the non-marker branch below, so the response lost
// `DeleteMarker`/`DeleteMarkerVersionId` and the removal was
// accounted as an object deletion (issue #6745).
let removed_delete_marker =
goi.delete_marker && dobj.version_id.is_some() && delete_file_info_version_id(goi.version_id) == version_id;
// Response-side only for the null identity: a delete request marked
// `deleted` with `version_id == None` makes `FileMeta::delete_version`
// re-create the marker it just removed (the suspended-bucket
// "delete mints a marker" write path), so the write shape must stay
// untouched for explicit null-marker removals.
if removed_delete_marker && version_id.is_some() {
vr.deleted = true;
vr.mod_time = goi.mod_time;
}
@@ -6540,11 +6555,21 @@ impl crate::storage_api_contracts::object::ObjectOperations for SetDisks {
}
};
if vr.deleted {
if vr.deleted || removed_delete_marker {
del_objects[i] = DeletedObject {
delete_marker: vr.deleted,
delete_marker_version_id: vr.version_id,
delete_marker_mtime: vr.mod_time,
delete_marker: true,
// `vr.version_id` holds the storage identity, which is
// `None` for an explicit null-marker removal; report the
// client-facing null identity so the response can carry
// `DeleteMarkerVersionId` for the marker that was removed.
delete_marker_version_id: if explicit_null_version {
Some(Uuid::nil())
} else {
vr.version_id
},
// For a null-marker removal `vr` stays undeleted (write
// shape), so take the marker's mtime from the source.
delete_marker_mtime: vr.mod_time.or(goi.mod_time),
object_name: vr.name.clone(),
replication_state: vr.replication_state_internal.clone(),
..Default::default()
@@ -7197,6 +7222,14 @@ impl crate::storage_api_contracts::object::ObjectOperations for SetDisks {
obj_info.user_defined = Arc::clone(&goi.user_defined);
obj_info.parts = Arc::clone(&goi.parts);
obj_info.user_tags = Arc::clone(&goi.user_tags);
// Report delete-marker semantics for an explicit-version delete whose
// target was a delete marker. On versioning-suspended buckets
// `resolve_delete_version_state` cannot mark the write request itself
// (a `deleted` write with the null identity re-creates the marker), so
// the marker-ness is restored on the response here (issue #6745).
if explicit_delete_removed_marker(&opts, &goi, version_found) {
obj_info.delete_marker = true;
}
self.invalidate_get_object_metadata_cache(bucket, object).await;
Ok(obj_info)
}