mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-06 03:59:14 +00:00
唐小鸭
c5e6b7259e
The bucket-meta receiver judged an incoming item stale by comparing its source `updated_at` with the `*_config_updated_at` stamp of the config on disk, but that stamp was the receiver's local clock at apply time (`BucketMetadata::update_config`). A source edit newer than the applied one but delivered after the local stamp was judged stale and acknowledged with 200: two quick source edits under delivery delay lose the second, and a peer clock ahead of ours loses every follow-up edit inside the skew. Add explicit-timestamp write entries, expanding rather than changing the existing ones: - `BucketMetadata::update_config_at`; `update_config` delegates to it with the local clock. - `metadata_sys::update_if_incarnation_at`, `update_under_transaction_lock_at`, `update_quota_if_incarnation_at`, threaded through the shared write-guard path as `Option<OffsetDateTime>` (`None` keeps local stamping for every existing caller and for deletes). - Re-exported through the ecstore `api` facade and the rustfs admin `storage_api::metadata_sys` facade. `apply_bucket_meta_item` now persists policy, tags, versioning, object-lock, sse, replication, quota and cors configs with the item's source time, so the stored stamp equals the source `updatedAt` and staleness is judged source time against source time. Items without `updated_at` keep the local stamp. lc-config stays on the local stamp: its staleness axis is the in-document `expiry_updated_at` the merge records, and the whole-config time only serves as its deletion / legacy lower bound. Local (non-replicated) edits keep stamping the local clock — they are the source. (cherry picked from commit c1009c018b217ef9edc7773c8e56667ea7e77335)