165 Commits

Author	SHA1	Message	Date
Chris	2bdec2fdcd	chore(release): merge main into release (#7913) ... * feat(nightly): publish packages as assets of the rolling 'nightly' release (sync from release) (#7593) feat(nightly): publish packages as assets of the rolling 'nightly' release (#7592) Replace the assets-branch scheme with a proper GitHub Release on rustfs/auto-testing: a single 'nightly' release whose deb/rpm assets are replaced in place on every build. This is the standard channel — visible on the repo's Releases page, stable download URLs, no git history growth (release assets live outside the repository). - New scripts/release/publish_nightly_assets.sh: resolves-or-creates the 'nightly' release via the REST API, deletes same-name assets, uploads rustfs-nightly-latest.{deb,rpm}, then PATCHes the release body with the build provenance (ref@sha, run link, sizes, SHA256). Plain curl + python3, no gh CLI (the build fleet has none — #7586). - The workflow step shrinks to invoking the script; full flow exercised end-to-end against the real release with probe files (create / upload / overwrite / download round-trip / body update). * fix(ecstore): stop pruning at nonempty directories (#7616) * fix(ecstore): stop pruning at nonempty directories * test(ecstore): release pruning fixtures before temp cleanup * fix(replication): close the pre-stable convergence gaps from backlog#2367 (#7626) * fix(replication): total-order rule sort and honor V1 top-level Prefix Rule matching had two defects from the pre-GA replication audit (rustfs/backlog#2367 C-1 and C-2): - The actionable-rule sort compared same-destination rules by priority but answered Equal for any other pair, which is not a total order; the standard library sort panics on such comparators once a slice exceeds the insertion-sort threshold, so an object matching more than 20 enabled rules across two or more targets could panic the PUT or DELETE task. Rules now sort by priority descending with destination and id as tie-breakers, and filter_target_arns preserves that order instead of draining a HashSet. - A V1 rule written without a <Filter> carries its prefix at the top level; that field was never read, so <Prefix>logs/</Prefix> matched every object. ReplicationRuleExt::prefix now falls back to it, with a <Filter> keeping precedence. The existing prefix fixtures were built this way and had been asserting nothing. * fix(admin): advertise data-usage and listen capabilities to rc The rc client gated `rc du` and `rc watch` on a pinned contract that matched server versions by the string prefix `1.0.0-rc.`; a server that reports `1.0.0` no longer matches, and the dynamic `advertised` list did not carry either name, so `rc du` against a GA server fails with an unsupported-capability error (rustfs/backlog#2367 E-2). Advertise `admin.data-usage` from the admin route inventory like the IAM entries, and `listen_notification` for the bucket `?events=` extension route the admin router dispatches. The client merges advertised entries ahead of its pinned contract, so no version sniffing is needed. * fix(site-replication): stop notifying the local site on remove and rotate The pending-remove and pending-rotation notification loops skipped the local site by endpoint only, while finalization identifies it by deployment id or endpoint. The reconcile tick resolves the local peer from the node's own listen address (and a handler from the request Host), so `remove --all` dialed the site's registered endpoint, waited out the request timeout against the lifecycle lock it was holding, and answered `Partial: failed to notify 1 peer(s)` for a removal that had succeeded (rustfs/backlog#2367 A-4, backlog#2195 item 3). Both loops now iterate the peers still awaiting notification through one helper that applies the finalization identity. * fix(site-replication): promote and settle IAM retries without a tick of slack Two retry-queue behaviours kept an IAM change from converging for ten to twenty minutes after a peer came back (rustfs/backlog#2367 A-1 and A-3, backlog#2305): - The lightweight 30-second pass filtered its reachability probe to bucket ops, so a backed-off IAM or bucket-metadata snapshot waited for the 600-second tick to notice the peer. It now probes every backed-off class and still replays only bounded bucket ops; promotion is a state flip the heavyweight tick acts on. - Backoffs are multiples of the tick interval, so a failure stamped δ seconds after a tick was 600 − δ old at the next tick and slipped a whole extra interval. The heavyweight drain now evaluates backoff halfway to its next tick. - An IAM entry first created by a non-deletion failure (the add bootstrap's snapshot send, the drain's own replay, an import-iam schedule) was never stamped `deletions_recorded`, so a later recorded deletion could not settle it and it escalated to the marker only `replicate repair` clears. Entries created by this binary now start recorded; a row persisted by an older binary keeps the escalation semantics. * fix(site-replication): reload peer node caches after bucket wiring writes Every S3 bucket-config write ends by asking the other nodes of the cluster to reload the bucket's metadata; the site-replication writers never did. On a multi-node site the node that ran the pairing (or applied a peer's bucket-meta item) rewrote the bucket targets and the derived replication rules on disk, while every other node kept serving its cached copy for up to the 15-minute refresh. A `resync start` routed to such a node reported every freshly wired bucket as `Config not found` and a bucket whose operator target the pairing had replaced as `recorded remote target no longer exists` (rustfs/backlog#2367 A-5, backlog#2195 item 2; functional SITE-105). Add one best-effort reload helper in the site-replication hooks and call it after the bucket setup, versioning, peer bucket-meta apply, removed-peer cleanup, make-with-versioning, and endpoint-refresh writes; the ensure helpers now report whether they wrote so unchanged passes stay silent. The resync manifest and start now read the persisted wiring instead of the node-local cache, matching the target read the start path already did. The new four-node e2e pairs two clusters and starts a resync through a non-coordinator node right after pairing; it also covers an IAM user created on a non-coordinator node converging to the peer site. * test(e2e): cover delete-marker replication from a multi-node source The functional suite reported delete markers created on a 3-node source never reaching the target (rustfs/backlog#2195 item 4, REP-105). The report was a probe defect, but the shape had no coverage: the existing delete-marker e2e runs a single-node source. Pin it against a four-node source replicating to a four-node peer and to a single-node target, with the write and the delete issued through different nodes. * ci(e2e): refresh the distributed selection for the new replication cases Four distributed cases were added (two site-replication, two delete-marker replication). The linux digest is derived from the last CI listing of the lane (34 cases, matching the previous pin) plus the four new names; the darwin digest is the local listing, which selects the same 38 cases. * feat(console): support a configurable console URL prefix (#7634) Co-authored-by: houseme <housemecn@gmail.com> * chore(release): merge release into main for rc.6 (#7638) * test(heal): cover MRF manifest CAS legacy transition (#7443) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(ci): enable release branch checks and repair test imports (#7441) * test(scanner): structure heal release evidence lanes (#7442) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): require segment producer identities (#7444) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): expose recovery intent identity (#7445) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): summarize failed heal perf reports (#7446) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(common): retain unmatched MRF repair proofs (#7447) Add a recorded verified-repair consumer that discharges only exact retained anchors for the requested bucket while leaving unmatched proofs in the event ring. This gives the future durable successor writer a fail-closed primitive before any tombstone or GC path is enabled. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(ci): route replication read plan through boundary (#7448) * test(scanner): cover flat-bucket quantum fairness (#7449) Add a production-entry scanner cohort regression that combines a wide flat bucket with a small bucket under a fixed object budget. The test keeps partial budgeted rounds unpublished, verifies small buckets are only marked after real execution, and confirms a later unbudgeted round can publish the complete aggregate. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(heal): reuse same admission request id (#7451) Keep a retried heal start with the same request id from bypassing admission deduplication when the transport replay cache is unavailable but the manager still owns the task. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require perf summary evidence fields (#7453) Fail closed when measured passing Scanner/Heal ABBA summaries omit W10/W11 foreground pressure, lock wait, or attempt-cost evidence. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): bind release evidence fields (#7452) Require explicit scanner/heal release evidence field contracts for the scoped ACK and mixed-version rollback gates. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): tag dirty usage producer identities (#7454) Record production-facing segment invalidation producer identities when existing object-level dirty usage hooks observe PUT, CopyObject, DeleteObject/DeleteMarker, and CompleteMultipartUpload mutations. Keep the data non-authoritative and process-local so segment reuse activation still requires durable generation-window proof. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): gate release evidence bundles (#7457) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require hard evidence ABBA manifest (#7459) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * feat(heal): add MRF committed snapshot writer (#7458) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover EC8+4 restart shard rebuild (#7461) Retry heal-control RPCs once after transport auth rejects a stale replay-scope epoch, and add a distributed EC8+4 restart heal evidence case that rebuilds a replaced drive with exact shard/body assertions. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): echo measured release evidence in ABBA fake adapter (#7460) Keep the synthetic ABBA test adapter aligned with the measured release evidence contract so result validation covers release_evidence drift. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require complete ABBA summary matrix (#7462) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * heal: retain MRF replay journal after accepted/merged replays Keep startup replay journal until a durable successor snapshot exists after Accepted/Merged admission. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: reclaim superseded MRF snapshots after readback Add a committed snapshot predecessor cleanup primitive that deletes only an older slot after the successor is read back as the current committed snapshot. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: require exact owner for object receipts Require object heal receipts to match the expected bucket incarnation before they can be recorded as positive repair evidence. This prevents stale or cross-incarnation receipts from clearing the wrong heal responsibility. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: latch object receipt owner before repair Capture the expected bucket incarnation before invoking object repair so a post-repair owner change cannot rewrite the responsibility that a storage receipt is allowed to prove. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: replay committed MRF checkpoints durably (#7465) Prefer committed MRF checkpoints during startup replay, retain accepted replay responsibilities until exact verified repair proofs arrive, and reclaim committed manifests only after discharge. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): bind hard evidence bundle provenance (#7467) Require Scanner/Heal release bundle fields to carry source, run, window, timestamp, command, and artifact format provenance before a measured gate can pass. Keep EC8+4 and performance gate fields tied to a single measurement window so unrelated artifacts cannot be stitched into a release approval. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * heal: reject dry-run object repair receipts Do not record positive storage repair receipts for dry-run object heal tasks, even if a producer accidentally returns a matching receipt. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: reject cancelled object repair receipts Do not record positive storage repair receipts once an object heal task has been cancelled, even if the receipt still matches the requested owner and object identity. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(heal): reject failed object repair receipts Cover the receipt consumer path where a storage repair result carries both an error and a matching positive receipt. The failure may be recorded, but the receipt must not create repaired, healthy, or absent proof. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(heal): cover bucket object repair receipts (#7468) Cover bucket and root heal sweeps recording authoritative object outcomes only when storage receipts match the latched bucket incarnation. Verify unavailable or stale receipt ownership keeps object repair execution intact while leaving canonical outcome proof as Unknown. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): add EC8+4 heal restart evidence (#7469) Register and wire Scanner/Heal background target restart and crash evidence cases for the 3x4 EC8+4 topology. Validate the observed data/parity geometry in scanner-heal evidence receipts so multi-drive runs cannot satisfy the gate without proving EC8+4 metadata. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * heal: verify replacement pool metadata repair (#7471) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover quorum and mixed repair receipts Add focused oracles for transient quorum results that carry a matching receipt and for mixed grace plus repaired receipt batches. Only the repaired object may produce positive proof. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * heal: verify admin recreate pool metadata (#7474) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * heal: preserve merged result for duplicate submits Keep same-request-id replay receipts accepted for the receipt API, but preserve the legacy submit_heal_request duplicate admission result as Merged. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(heal): preserve EC84 restart semantics (#7478) Keep the EC8+4 background restart lane on the graceful-stop path and assert clean-restart marker absence only for restart scenarios. This prevents the hard evidence gate from silently exercising the crash path when it claims restart coverage. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover MRF snapshot torn successor recovery Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(heal): write EC84 distributed restart oracle (#7481) Bind the distributed EC8+4 restart evidence lane to a scanner/heal oracle artifact so release validation can consume the real nextest run instead of accepting only a passing test. Require the registry to assert 8+4 erasure geometry for the three-node, four-drive case. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(heal): harden MRF replay boundaries (#7483) Reject journal records with unknown version-presence flags even when their CRC is valid, so rollback/future payloads cannot be accepted as known records. Gate committed checkpoint cleanup by the writer owner captured from the replay source, preserving retained manifests from other owners inside the same sequence window. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(ecstore): bind MRF manifest CAS dirsync recovery (#7482) Cover the committed MRF manifest path through LocalDisk conditional CAS when the metadata directory fsync fails. The fixture proves the previous manifest anchor survives rollback, an unanchored first successor is removed, and the legacy MRF journal remains readable even while global durability is relaxed. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): derive evidence runner profile from registry (#7484) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require mixed-version evidence roles (#7485) Tighten the Scanner/Heal release bundle checker so mixed-version, scoped-ACK, and rollback fields cannot reuse a generic versions list without proving the expected evidence role. Require version lists to use source revision identities and include the tested source revision. Also require profile evidence fields to name the core profiling artifacts before release approval. The release gate remains blocked until measured field evidence is present. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(heal): publish committed MRF runtime checkpoints (#7490) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): bind profile artifacts in release evidence (#7487) Require Scanner/Heal release bundles to attach every required profiling artifact to P1 profile evidence with relative paths, artifact formats, non-empty files, hashes, and optional per-artifact measurement-window checks. Document the tightened release bundle profile contract and cover missing, tampered, and mismatched-window profile artifact regressions in the existing checker self-test. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): harden measured ABBA evidence claims (#7491) Reject measured Scanner/Heal ABBA manifests whose mixed-version evidence uses the same baseline and candidate source revision or binary hash. Require crash fault modes and profile artifact names to match the exact supported sets, rejecting missing, duplicate, and unknown values. Update harness fixtures and regression coverage for same-build mixed-version claims and exact-set release evidence fields. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(e2e): group scanner heal evidence payload (#7494) Group the EC8+4 Scanner/Heal evidence writer inputs into a typed payload so the distributed e2e crate stays within the clippy argument limit without weakening the lint. The evidence writer still validates the same S3 bodies, physical shard census, process restart PIDs, and node listings. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF replay bundle fields (#7486) Bind Scanner/Heal release bundle evidence for MRF durable replay to replay counts, retained responsibility anchors, and successor snapshot publication evidence. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): profile EC84 evidence case runs (#7495) Give Scanner/Heal evidence cases explicit runtime profiles so EC8+4 background restart and crash cases use their own object count, object size, and partial-progress timeout defaults instead of inheriting the legacy 4x1 case assumptions. Expose the runtime profile in plan-only output and cover every registry case in the script self-test. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): reject empty release evidence artifacts (#7496) Require Scanner/Heal release bundle artifact paths to resolve to non-empty files before hashing them. Cover empty hard-gate artifacts in the existing release bundle checker self-test and keep profile artifact size checking on the shared artifact boundary. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require G14 same-window field coverage (#7489) Tighten the Scanner/Heal release bundle checker so G14 same-window evidence must name the EC8+4, multi-set, and multi-pool fields covered in that measurement window. Keep the release gate blocked when same-window evidence omits one of the required G14 fields, without changing production runtime behavior. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require two-hour measured ABBA windows (#7493) Reject measured Scanner/Heal release ABBA manifests and summaries whose evidence window is shorter than the W21 two-hour release requirement. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover MRF idle checkpoint cleanup (#7497) Add a runtime cleanup regression test that publishes both retained replay and runtime committed checkpoints, writes scoped and legacy journals, and verifies idle cleanup removes every recovery anchor from the registered local disks. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(e2e): ignore untracked files in build identity (#7498) Align e2e_test build provenance with Scanner/Heal evidence receipts and server binary provenance by treating only tracked source changes as dirty. This prevents unrelated untracked worktrees or evidence directories from causing compiled test identity mismatches before real evidence cases can run. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF disk-full evidence fields (#7499) Require the Scanner/Heal release registry and bundle checker to carry explicit G08 MRF capacity, disk-full, and replica-loss evidence fields before release approval can pass. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): bind release JSON artifact provenance (#7500) Require scanner/heal release evidence JSON artifacts to repeat their measured source revision, run identity, measurement window, gate, and field identity inside the artifact payload. This keeps a refreshed outer bundle hash from accepting stale summary or profile JSON from another run. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover MRF rollback mirror filtering (#7501) Add a regression oracle that keeps scoped-only MRF responsibilities in the authoritative runtime snapshot while omitting them from the v1 legacy rollback mirror. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require segment activation evidence (#7504) * test(scanner): require segment activation evidence Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(scanner): cover activation proof inputs Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF crash matrix cases (#7505) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require release bundle domain evidence (#7502) Reject scanner/heal release bundles that omit field-level domain evidence for scoped ACK, durable intent, mixed-version, scheduler pressure, profile cost, and two-hour pressure lanes. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF retention GC evidence (#7506) Require P4 retained-responsibility release bundle evidence to list the retained replay anchor and idle cleanup cases, prove a two-hour retention window, and record both idle cleanup and verified-proof discharge observations. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF cleanup GC soak evidence (#7507) Require the P4 release bundle to carry measured cleanup/GC soak evidence for retained MRF replay responsibilities. The bundle now needs a two-hour cleanup window, exact cleanup case coverage, observed verified idle GC, and zero pending responsibilities or stale journals after GC. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): cover MRF disk-full commit anchors (#7509) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(e2e): report port allocator bind errors (#7510) Surface the scanned port window, attempt count, and last bind error when the e2e port allocator cannot reserve a localhost port. This keeps Scanner/Heal evidence failures actionable when the environment blocks binds before business assertions run. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(sse): resolve 1.0.0 SSE/KMS blockers and P1 findings (#7511) * fix(sse): resolve bucket default encryption per request PUT and the POST-object/extract path resolved a bucket's default encryption with a hard-coded "no explicit SSE-C" flag, so the default was layered onto a request that already carried an SSE-C header triple and then tripped that request's own mutual-exclusion check. Every bucket with default encryption refused SSE-C single PUTs with 400 InvalidArgument, while CreateMultipartUpload on the same bucket succeeded because it resolves SSE elsewhere. Both call sites now derive the flag from the request headers, as COPY already did. The bucket default's KMS key id was also inherited independently of the effective algorithm, so an explicit AES256 request against an aws:kms default bucket produced a self-contradictory algorithm/key-id pair and was rejected. The key id is now inherited only when the effective algorithm is aws:kms, matching the storage-layer resolver. Refs backlog#2368 B1, B2. * fix(sse): refuse SSE-KMS without a running KMS service A write requesting aws:kms on a node with no KMS service fell back to the node-local SSE-S3 provider: the data key was wrapped with RUSTFS_SSE_S3_MASTER_KEY while the object metadata still recorded aws:kms and the requested KMS key id. The stored object claimed a KMS protection it never had, under a key that was never consulted, and no signal distinguished it from a genuine SSE-KMS object. The managed-encryption path now asks the resolved DEK provider whether it wraps with a node-local master key and refuses SSE-KMS in that case: InvalidRequest when KMS was never configured, ServiceUnavailable when a configured service is not running. The check sits after the per-key authorization gate so an unauthorized caller still receives AccessDenied whatever the KMS runtime state is, and asks the provider rather than a parallel availability signal because the provider is what actually wraps the key. A missing master key no longer answers an SSE-KMS request with an SSE-S3-worded configuration error. The SSE-S3 local fallback is unchanged. Refs backlog#2368 B4. * fix(ecstore): restore and archive tiers in stored coordinates Multipart restore addressed the remote tier in plaintext coordinates while the copy-back reads the stored representation. Each part received a misaligned slice of the remote object whose length still satisfied the range, the hash reader and the completion size check, so the restore reported success and silently replaced the object's bytes. Encrypted and compressed multipart objects were both affected. Restore now accumulates stored part sizes, passes the stored length to the hash reader alongside the plaintext length, and validates against the stored size. The copy-back digests stored bytes, so its computed MD5 is not the object's public ETag. Restore now preserves the object ETag on both the single-part and multipart paths, and gives each restored part its own recorded part ETag rather than the object-level value. Transition also handed the tier the object's SSE headers and its RustFS-wrapped data key as request headers. Any S3 target rejected an SSE-C archive outright, an SSE-KMS archive asked the target to encrypt a second time under a key id it does not own, and the wrapped DEK left the cluster. The archive request now strips every SSE header and encryption marker with the predicate the replication path already uses; the local xl.meta keeps all of it, so read-through and restore are unaffected. Objects restored by an affected release are not detected or repaired retroactively and must be re-restored from the tier. Refs backlog#2368 B3, B5; backlog#2369 P7.1. * fix(rio): lock the v1 nonce layout within a segment Decrypting a v1 segment tried three historical nonce layouts per frame, independently for every frame. The last of them exists for streams written before 1.0.0-alpha.91, which reused a segment's part nonce for every block in it; because block zero's derived nonce equals that base nonce, a frame encrypted at index zero authenticated at any position. An attacker able to rewrite the underlying shards could replay it and have the forged plaintext returned with 200 and an unchanged length. Shard integrity uses a keyed-hash-free checksum, which such an attacker can recompute, so it is not a barrier. A segment now locks onto whichever layout decoded its first non-zero-index frame and rejects any later frame needing a different one. That leaves one residual shape: a stream built purely from repeats of frame zero has no later frame to disagree. New RUSTFS_ENCRYPTION_LEGACY_NONCE_FALLBACK (default true, so pre-alpha.91 objects keep decrypting) drops the third layout entirely when set to false, which closes it. Turning it off refuses pre-alpha.91 objects, so migrate them first by rewriting in place. Refs backlog#2369 P2. * fix(kms): reload a service that failed to start POST /rustfs/admin/v3/kms/reload short-circuited whenever the persisted configuration matched the in-memory one byte for byte. A node whose KMS failed to start keeps that configuration and sits in Error, so the documented recovery call returned "reloaded successfully" while leaving the node down. Peers reached the same path through the reload broadcast, so a cluster that lost Vault during a rolling restart had no working recovery route other than the node-local start endpoint. Reload now short-circuits only for a service that is actually running, and otherwise reconfigures, which starts a service that is not running. The AWS backend also advertised key-version enumeration through kms/status, which its own documentation says it cannot do; the capability and its golden snapshot now say false. Refs backlog#2369 P1, P7.3. * docs: record the SSE and KMS changes for 1.0.0 The Unreleased changelog section carried no entry for any encryption work merged since 1.0.0-rc.5, including three items with operational impact: the config-secret variable whose absence persists secrets in cleartext with only a warning, the v2 frame write switch and its rolling-upgrade constraint, and per-key authorization making a public bucket incompatible with SSE-KMS objects. Adds those plus this batch, including the SSE-KMS refusal as a breaking change with both routes out. Also corrects four places where documentation contradicted the code: the cleanup register still called encrypted range seek opt-in after its default flipped, the Helm README claimed vault_mount_path only applies to Transit while the template also feeds the KV2 mount, the disaster-recovery drill listed bundle contents for backends whose export is refused with 501, and the Chinese README capability table predated most of the feature set. Documents the SSE-S3 local master key as a first-class operational mode with its rotation dead end, and what the v1 frame layout does and does not authenticate. Refs backlog#2369 P5. * fix(kms): classify data-path KMS failures by what the caller can do Only "key not found" and a backend outage were classified; every other KMS failure that reached the S3 data path fell through to 500 InternalError with a generic message. A disabled or pending-deletion key, a denied KMS grant, an encryption-context mismatch, an unsupported algorithm, a credential or timeout failure, and a capability the configured backend does not have all looked identical to a server fault. SDKs therefore applied exponential backoff to configuration errors no retry can fix, and monitoring counted every one of them against the server's own error rate. Unusable-key and request-side failures now answer 400, a denied grant 403, transient backend failures 503, and a missing backend capability 501. Damaged, unreadable, or unknown-format key material keeps its 500: it is a server-side integrity fault, and existing tests pin it. The classifier is deliberately separate from the admin lifecycle mapping, which answers 404 for a missing key because there a key id is the resource being addressed; on the data path it arrives inside a request header or a bucket default. Messages either name what the caller asked for or stay generic, with deployment-side detail left on the error source the way the storage-IO mapping already does. Refs backlog#2368 B6. * fix(kms): track and renew static Vault tokens Token authentication hard-coded "this token carries no lease", so the renewal task never started, the remaining-TTL gauge was never published, and nothing looked wrong. `vault token create` grants a 768-hour TTL by default, so a cluster that had been healthy for a month turned every KMS call into a 403 and could not recover without a restart or a reconfigure. Production configuration validation only rejects the literal dev-token, so an ordinary expiring token reaches a whole cluster. The source now reads `auth/token/lookup-self` at login and adopts what Vault reports. A token with no expiry behaves exactly as before. An expiring renewable one is picked up by the existing renewal loop and renewed at half TTL like every other auth method. An expiring non-renewable one warns with its remaining lifetime and publishes the gauge, so the fail-closed window is visible before it arrives. The probe never fails the login: a policy that omits lookup-self, or a Vault that is briefly unreachable, warns and falls back to exactly the previous behaviour rather than taking down a deployment that works today. The scripted Vault test double answers the lookup out of band so existing scripts keep describing only the protocol under test. Refs backlog#2369 P3. * feat(sse): report SSE-C requests that arrive without TLS An SSE-C request carries the customer's AES key in a request header, so AWS S3 and MinIO both refuse one that did not arrive over TLS. RustFS accepted them on any transport: a plaintext hop hands the key to anyone on the path, and since the object cannot be read without that same key, the exposure lasts as long as the object does. Refusing outright is the correct end state but not a safe default to adopt inside a release window, because the project's own s3-tests and e2e lanes and most staging deployments speak plain HTTP. This release reports instead: each such request increments rustfs_ssec_plaintext_requests_total and logs one warning per process, so an operator can confirm nothing would break before the default flips. RUSTFS_SSE_C_REQUIRE_TLS=true opts into the AWS 400 now. The verdict is per connection rather than per deployment: the layer is built with whether this listener terminated TLS, and additionally accepts an https protocol forwarded by a proxy the trusted-proxy configuration already vetted. It sits beside the rate limiter, after the layer that makes a forwarded protocol trustworthy and after the request context, so a rejection can echo the request id. Refs backlog#2369 P7.2. * fix(kms): say what a node-local backend means for a cluster The Local backend keeps key material on each node's own disk and generates its Argon2id salt per node, so two nodes derive different keys from the same master_key and an object encrypted on one node cannot be decrypted on another. Behind a load balancer that surfaces as intermittent 500s on reads that succeeded moments earlier, with nothing tying the symptom to the cause: the only signal was a generic "development, testing and demos only" positioning warning that says nothing about what actually breaks. Configuring or reconfiguring Local while the deployment is distributed now logs a dedicated event and appends the consequence to the configure response, so the operator who made the change sees it. The product decision to warn rather than refuse is unchanged. Refs backlog#2369 P7.4. * docs: record the remaining SSE and KMS changes for 1.0.0 Adds changelog entries for the KMS data-path status classification, the Vault static-token lease probe, the SSE-C plaintext-transport report and its switch, and the node-local backend warning. Documents two things the backend security guide never stated: that SSE-C belongs on a secure transport, with the counter and switch to plan the change around, and that the Local backend cannot be shared by a multi-node deployment because each node derives different keys from the same master key. Refs backlog#2368 B6; backlog#2369 P3, P5, P7.2, P7.4. * fix(kms): report an unreadable key store as an outage on the S3 path A backend now distinguishes a key store it could not read from a key that is genuinely absent, but the S3 boundary collapsed the first one back onto 500 InternalError through the fallthrough for integrity faults. The distinction was therefore invisible to the client: a temporary key-directory outage looked exactly like a permanently damaged key record, and neither the status nor the metric said the request was worth retrying. An unreadable key store joins the retryable class and answers 503, next to a backend error and a credential failure. Damaged, unreadable or unknown-format key material keeps its 500. Refs backlog#2368 B6; builds on rustfs/rustfs#7470. * test(storage): cover MRF cleanup delete ENOSPC anchor (#7513) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require heal retry stats evidence (#7514) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): add release bundle dry-run fixture (#7515) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): confirm recovery intent accept readback (#7516) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require MRF cleanup delete ENOSPC evidence (#7518) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): require bounded retry window evidence (#7517) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(e2e): emit scanner heal G09 upgrade evidence (#7519) Record measured Scanner/Heal G09 evidence artifacts from the upgrade compatibility lanes when a fresh evidence directory is provided. Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(heal): persist MRF rollback mirror boundary (#7520) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): add G09 upgrade evidence runner (#7522) * fix(replication): close the GA blocker set from backlog#2366 (#7503) * fix(replication): close GA blockers from backlog#2366 Implements the P1 set from the pre-GA replication audit: - Replication rule tag filters now require every And.Tag to match, replacing the s3s OR semantics with a local AND matcher that fails closed on a malformed tag. - A replicated group membership change no longer writes the group status, so a membership update carrying the default Enabled status cannot silently re-enable a disabled group on the peer. - A successful IAM import schedules one collapsed full-IAM snapshot per remote peer instead of leaving the imported entities local-only. - A pending endpoint refresh is redriven by the heavyweight reconcile tick, carries its own ilm-expiry override, and no longer blocks a remove that drops every unacknowledged peer. - Site metrics expose local replication failure totals and rolling windows; node-level counters no longer report a constructed zero. - set/remove-remote-target notify peer metadata caches before returning, so a follow-up put-bucket-replication on another node sees the target. - Adds the site-replication operations runbook, a docs index, a replication support boundary section, and the Replication changelog section. * fix(site-replication): resume only a locally driven endpoint refresh The peer-side edit handler journals a pending endpoint refresh with an empty `remote_peers` map and commits it inside the same request through `apply_internal_peer_edit`. The reconcile tick could not tell that journal from the coordinator's own: with no required peers it reads as complete on sight, so the tick committed it with `edit_state` - losing the local-name sync - and cleared it under the request that owned it, whose commit then reported the refresh as changed and denied the coordinator the peer acknowledgement it was waiting for. Resume now runs only for a journal that carries the fan-out topology. A receiver's journal stays for the coordinator to redrive with the same refresh id, which is the path that already recovers it. * fix(site-replication): keep an explicit disabled group status on a snapshot Skipping the group-status write whenever an item carries members stopped a membership change from re-enabling a disabled group, but it also silenced the full-IAM snapshot, which always sends members together with the sender's real status. A peer that did not have the group yet created it through `GroupInfo::new` - enabled - so a bootstrap, a repair, or the snapshot an IAM import now schedules handed every member of a frozen group live access there. The madmin wire maps an unset `groupStatus` to Enabled, so only Enabled can be a default. Disabled is always explicit and is applied again. * fix(site-replication): schedule the import snapshot without recording a failure `import-iam` reused the failure-recording path to queue its full-IAM snapshot. That raises `retry_count` on every call, so three imports - the normal shape of a bulk migration done one archive at a time - escalated a healthy peer to `retryStats.failed` with the scheduling note shown as `lastError`, which is exactly the signal the runbook tells operators to repair. A full retry queue also turned a completed import into a 503. Scheduling now only ensures the collapsed entry exists, and a failure to schedule is logged instead of failing the request: the entities are already imported and the reconcile pass still closes the gap. * fix(admin): stop reporting replication failures as retries `retries` is the minio-go counter for redeliveries, and mc prints it as such. Filling it with the failure count claimed a redelivery that never happens: a failed object is not retried by an event today, it waits for the scanner heal pass. `errors` keeps the failure counters; `retries` stays zero until there is a real redelivery to count, and the runbook now says so. * perf(site-replication): aggregate failure windows without cloning bucket stats `site_metrics_snapshot` went through `get_all`, which clones every bucket's stats, and then scanned each target's sample deque twice. That deque is bounded only by the one-hour window, so an unreachable target under load - the case an operator polls this endpoint for - made every `mc admin replicate status` copy the whole backlog and hold the read lock against the failure path while doing it. It now folds under the read lock and takes both windows in one walk. The `max` against the serialized `last_minute` / `last_hour` snapshots is dropped: those are stamped onto per-bucket clones elsewhere and are always zero in this node-local cache. * fix(site-replication): reject a conflicting ilm-expiry override on a re-run The commit now reads the ilm-expiry override back out of the pending refresh journal, so a second edit that asks for a different value had it dropped while the request still reported success. Re-running without the flag keeps pinning the recorded value - that is the documented way to redrive a stuck refresh - but an explicit different value is now rejected instead of ignored. * fix(admin): do not fail a remote-target write on a peer reload error set/remove-remote-target propagated the peer metadata reload error, so a target that was already persisted and live on this node reported a 5xx to the client whenever one peer could not be reached. Every S3 bucket-config write path treats that reload as best effort and only warns; these two admin handlers now do the same, and the reason is logged with the bucket and action. * fix(site-replication): undo every bucket a cut-short refresh rewrote When a remove accepted on another node clears the refresh journal mid-pass, only the bucket holding the lock at that moment had its restored target undone. The buckets rewritten earlier in the same pass kept a target pointing at the removed peer whenever the remove's own cleanup had already walked past them. The undo now covers every bucket this pass rewrote, attempting all of them so one failure does not strand the rest. * fix(site-replication): keep replay running while an endpoint refresh is pending A pending endpoint refresh took the whole heavyweight pass with it, so a peer that never came back froze IAM and bucket replay to every healthy peer too - the stall this journal's resume path was meant to end. The refresh arm now drains the retry queue before returning; it replays per-peer deliveries against the endpoints currently committed in state, so it is unaffected by the edit in flight. Bucket wiring reconciliation still waits, because it rewrites the very targets the refresh is changing, and the runbook now says so. * test(e2e): cover the AND semantics of a two-tag replication filter The acceptance matrix only had a single-tag rule, which matches under both AND and OR semantics and therefore proved nothing about the filter this fix changed. It now also carries a two-tag `And` rule - the shape `mc replicate add --tags "k1=v1&k2=v2"` writes - and asserts that an object with one of the two tags is not admitted while an object with both is. No new test function, so the nightly selection digest is unchanged. * refactor(site-replication): fold the refresh state-change error into one constructor The endpoint-refresh work added three `s3_error!` invocation lines, which the s3s footprint ratchet is meant to prevent. Five copies of the same concurrent-change error now share one constructor, so the surface nets one line smaller than main; the baseline is retightened to match. * fix(site-replication): report a peer whose IAM snapshot waits for a repair An escalated snapshot entry records a deletion a snapshot cannot replay, so only a repair settles it and the marker must survive. Scheduling an import snapshot therefore leaves that peer's entry alone - and now says so, instead of returning success while nothing was scheduled for it. * docs(operations): state the group-status and escalation convergence limits Two boundaries the fixes in this branch make load-bearing: a membership change never carries an enable, so a group disabled on one site only has to be re-enabled there explicitly; and a peer holding an escalated IAM entry does not receive a scheduled snapshot, including the one a bulk import schedules, until a repair settles it. * fix(ci): bind performance runs to selected inputs (#7512) * test(scanner): add G09 upgrade evidence runner Add a reusable Linux x86_64 runner for the Scanner/Heal G09 mixed-version and rollback upgrade evidence lanes. The helper reads the pinned previous-release asset metadata from the upgrade workflow, verifies the downloaded binary, builds the current head, runs both ignored E2E tests, and fails unless the expected G09 JSON artifacts exist. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: 唐小鸭 <tangtang1251@qq.com> Co-authored-by: Zhengchao An <anzhengchao@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com> * feat(scanner): implement V2 evidence preflights (#7523) * feat(scanner): wire dirty usage producer identities Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test(scanner): add segment activation preflight proof Keep scanner segment reuse behind a structured activation preflight so release evidence can prove the production gate remains disabled until every producer, generation, overflow, cold-oracle, and distributed invalidation check is satisfied. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * feat(scanner): expose distributed invalidation evidence Record an explicit distributed segment invalidation evidence summary when remote dirty usage snapshots are bound to the current activity window and the authenticated scoped ACK capability probe succeeds. Reject peer dirty usage snapshots that contradict the peer activity pending bit so scoped ACKs fail closed instead of clearing an unadvertised remote mutation. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): assemble release evidence bundles (#7526) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): add G09 upgrade evidence runner (#7524) * fix(replication): close the GA blocker set from backlog#2366 (#7503) * fix(replication): close GA blockers from backlog#2366 Implements the P1 set from the pre-GA replication audit: - Replication rule tag filters now require every And.Tag to match, replacing the s3s OR semantics with a local AND matcher that fails closed on a malformed tag. - A replicated group membership change no longer writes the group status, so a membership update carrying the default Enabled status cannot silently re-enable a disabled group on the peer. - A successful IAM import schedules one collapsed full-IAM snapshot per remote peer instead of leaving the imported entities local-only. - A pending endpoint refresh is redriven by the heavyweight reconcile tick, carries its own ilm-expiry override, and no longer blocks a remove that drops every unacknowledged peer. - Site metrics expose local replication failure totals and rolling windows; node-level counters no longer report a constructed zero. - set/remove-remote-target notify peer metadata caches before returning, so a follow-up put-bucket-replication on another node sees the target. - Adds the site-replication operations runbook, a docs index, a replication support boundary section, and the Replication changelog section. * fix(site-replication): resume only a locally driven endpoint refresh The peer-side edit handler journals a pending endpoint refresh with an empty `remote_peers` map and commits it inside the same request through `apply_internal_peer_edit`. The reconcile tick could not tell that journal from the coordinator's own: with no required peers it reads as complete on sight, so the tick committed it with `edit_state` - losing the local-name sync - and cleared it under the request that owned it, whose commit then reported the refresh as changed and denied the coordinator the peer acknowledgement it was waiting for. Resume now runs only for a journal that carries the fan-out topology. A receiver's journal stays for the coordinator to redrive with the same refresh id, which is the path that already recovers it. * fix(site-replication): keep an explicit disabled group status on a snapshot Skipping the group-status write whenever an item carries members stopped a membership change from re-enabling a disabled group, but it also silenced the full-IAM snapshot, which always sends members together with the sender's real status. A peer that did not have the group yet created it through `GroupInfo::new` - enabled - so a bootstrap, a repair, or the snapshot an IAM import now schedules handed every member of a frozen group live access there. The madmin wire maps an unset `groupStatus` to Enabled, so only Enabled can be a default. Disabled is always explicit and is applied again. * fix(site-replication): schedule the import snapshot without recording a failure `import-iam` reused the failure-recording path to queue its full-IAM snapshot. That raises `retry_count` on every call, so three imports - the normal shape of a bulk migration done one archive at a time - escalated a healthy peer to `retryStats.failed` with the scheduling note shown as `lastError`, which is exactly the signal the runbook tells operators to repair. A full retry queue also turned a completed import into a 503. Scheduling now only ensures the collapsed entry exists, and a failure to schedule is logged instead of failing the request: the entities are already imported and the reconcile pass still closes the gap. * fix(admin): stop reporting replication failures as retries `retries` is the minio-go counter for redeliveries, and mc prints it as such. Filling it with the failure count claimed a redelivery that never happens: a failed object is not retried by an event today, it waits for the scanner heal pass. `errors` keeps the failure counters; `retries` stays zero until there is a real redelivery to count, and the runbook now says so. * perf(site-replication): aggregate failure windows without cloning bucket stats `site_metrics_snapshot` went through `get_all`, which clones every bucket's stats, and then scanned each target's sample deque twice. That deque is bounded only by the one-hour window, so an unreachable target under load - the case an operator polls this endpoint for - made every `mc admin replicate status` copy the whole backlog and hold the read lock against the failure path while doing it. It now folds under the read lock and takes both windows in one walk. The `max` against the serialized `last_minute` / `last_hour` snapshots is dropped: those are stamped onto per-bucket clones elsewhere and are always zero in this node-local cache. * fix(site-replication): reject a conflicting ilm-expiry override on a re-run The commit now reads the ilm-expiry override back out of the pending refresh journal, so a second edit that asks for a different value had it dropped while the request still reported success. Re-running without the flag keeps pinning the recorded value - that is the documented way to redrive a stuck refresh - but an explicit different value is now rejected instead of ignored. * fix(admin): do not fail a remote-target write on a peer reload error set/remove-remote-target propagated the peer metadata reload error, so a target that was already persisted and live on this node reported a 5xx to the client whenever one peer could not be reached. Every S3 bucket-config write path treats that reload as best effort and only warns; these two admin handlers now do the same, and the reason is logged with the bucket and action. * fix(site-replication): undo every bucket a cut-short refresh rewrote When a remove accepted on another node clears the refresh journal mid-pass, only the bucket holding the lock at that moment had its restored target undone. The buckets rewritten earlier in the same pass kept a target pointing at the removed peer whenever the remove's own cleanup had already walked past them. The undo now covers every bucket this pass rewrote, attempting all of them so one failure does not strand the rest. * fix(site-replication): keep replay running while an endpoint refresh is pending A pending endpoint refresh took the whole heavyweight pass with it, so a peer that never came back froze IAM and bucket replay to every healthy peer too - the stall this journal's resume path was meant to end. The refresh arm now drains the retry queue before returning; it replays per-peer deliveries against the endpoints currently committed in state, so it is unaffected by the edit in flight. Bucket wiring reconciliation still waits, because it rewrites the very targets the refresh is changing, and the runbook now says so. * test(e2e): cover the AND semantics of a two-tag replication filter The acceptance matrix only had a single-tag rule, which matches under both AND and OR semantics and therefore proved nothing about the filter this fix changed. It now also carries a two-tag `And` rule - the shape `mc replicate add --tags "k1=v1&k2=v2"` writes - and asserts that an object with one of the two tags is not admitted while an object with both is. No new test function, so the nightly selection digest is unchanged. * refactor(site-replication): fold the refresh state-change error into one constructor The endpoint-refresh work added three `s3_error!` invocation lines, which the s3s footprint ratchet is meant to prevent. Five copies of the same concurrent-change error now share one constructor, so the surface nets one line smaller than main; the baseline is retightened to match. * fix(site-replication): report a peer whose IAM snapshot waits for a repair An escalated snapshot entry records a deletion a snapshot cannot replay, so only a repair settles it and the marker must survive. Scheduling an import snapshot therefore leaves that peer's entry alone - and now says so, instead of returning success while nothing was scheduled for it. * docs(operations): state the group-status and escalation convergence limits Two boundaries the fixes in this branch make load-bearing: a membership change never carries an enable, so a group disabled on one site only has to be re-enabled there explicitly; and a peer holding an escalated IAM entry does not receive a scheduled snapshot, including the one a bulk import schedules, until a repair settles it. * fix(ci): bind performance runs to selected inputs (#7512) * test(scanner): add G09 upgrade evidence runner Add a reusable Scanner/Heal G09 runner for Linux PR-head validation. The script downloads the pinned previous release, builds the current checkout, runs the mixed-version and rollback upgrade E2E lanes, and validates the measured raw artifacts before they can be consumed by the release bundle gate. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: 唐小鸭 <tangtang1251@qq.com> Co-authored-by: Zhengchao An <anzhengchao@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): replay recovery intents while disabled (#7521) Co-authored-by: zhi22915 <qiuzgang@gmail.com> * test(scanner): preflight G09 evidence disk space (#7527) * fix(replication): close the GA blocker set from backlog#2366 (#7503) * fix(replication): close GA blockers from backlog#2366 Implements the P1 set from the pre-GA replication audit: - Replication rule tag filters now require every And.Tag to match, replacing the s3s OR semantics with a local AND matcher that fails closed on a malformed tag. - A replicated group membership change no longer writes the group status, so a membership update carrying the default Enabled status cannot silently re-enable a disabled group on the peer. - A successful IAM import schedules one collapsed full-IAM snapshot per remote peer instead of leaving the imported entities local-only. - A pending endpoint refresh is redriven by the heavyweight reconcile tick, carries its own ilm-expiry override, and no longer blocks a remove that drops every unacknowledged peer. - Site metrics expose local replication failure totals and rolling windows; node-level counters no longer report a constructed zero. - set/remove-remote-target notify peer metadata caches before returning, so a follow-up put-bucket-replication on another node sees the target. - Adds the site-replication operations runbook, a docs index, a replication support boundary section, and the Replication changelog section. * fix(site-replication): resume only a locally driven endpoint refresh The peer-side edit handler journals a pending endpoint refresh with an empty `remote_peers` map and commits it inside the same request through `apply_internal_peer_edit`. The reconcile tick could not tell that journal from the coordinator's own: with no required peers it reads as complete on sight, so the tick committed it with `edit_state` - losing the local-name sync - and cleared it under the request that owned it, whose commit then reported the refresh as changed and denied the coordinator the peer acknowledgement it was waiting for. Resume now runs only for a journal that carries the fan-out topology. A receiver's journal stays for the coordinator to redrive with the same refresh id, which is the path that already recovers it. * fix(site-replication): keep an explicit disabled group status on a snapshot Skipping the group-status write whenever an item carries members stopped a membership change from re-enabling a disabled group, but it also silenced the full-IAM snapshot, which always sends members together with the sender's real status. A peer that did not have the group yet created it through `GroupInfo::new` - enabled - so a bootstrap, a repair, or the snapshot an IAM import now schedules handed every member of a frozen group live access there. The madmin wire maps an unset `groupStatus` to Enabled, so only Enabled can be a default. Disabled is always explicit and is applied again. * fix(site-replication): schedule the import snapshot without recording a failure `import-iam` reused the failure-recording path to queue its full-IAM snapshot. That raises `retry_count` on every call, so three imports - the normal shape of a bulk migration done one archive at a time - escalated a healthy peer to `retryStats.failed` with the scheduling note shown as `lastError`, which is exactly the signal the runbook tells operators to repair. A full retry queue also turned a completed import into a 503. Scheduling now only ensures the collapsed entry exists, and a failure to schedule is logged instead of failing the request: the entities are already imported and the reconcile pass still closes the gap. * fix(admin): stop reporting replication failures as retries `retries` is the minio-go counter for redeliveries, and mc prints it as such. Filling it with the failure count claimed a redelivery that never happens: a failed object is not retried by an event today, it waits for the scanner heal pass. `errors` keeps the failure counters; `retries` stays zero until there is a real redelivery to count, and the runbook now says so. * perf(site-replication): aggregate failure windows without cloning bucket stats `site_metrics_snapshot` went through `get_all`, which clones every bucket's stats, and then scanned each target's sample deque twice. That deque is bounded only by the one-hour window, so an unreachable target under load - the case an operator polls this endpoint for - made every `mc admin replicate status` copy the whole backlog and hold the read lock against the failure path while doing it. It now folds under the read lock and takes both windows in one walk. The `max` against the serialized `last_minute` / `last_hour` snapshots is dropped: those are stamped onto per-bucket clones elsewhere and are always zero in this node-local cache. * fix(site-replication): reject a conflicting ilm-expiry override on a re-run The commit now reads the ilm-expiry override back out of the pending refresh journal, so a second edit that asks for a different value had it dropped while the request still reported success. Re-running without the flag keeps pinning the recorded value - that is the documented way to redrive a stuck refresh - but an explicit different value is now rejected instead of ignored. * fix(admin): do not fail a remote-target write on a peer reload error set/remove-remote-target propagated the peer metadata reload error, so a target that was already persisted and live on this node reported a 5xx to the client whenever one peer could not be reached. Every S3 bucket-config write path treats that reload as best effort and only warns; these two admin handlers now do the same, and the reason is logged with the bucket and action. * fix(site-replication): undo every bucket a cut-short refresh rewrote When a remove accepted on another node clears the refresh journal mid-pass, only the bucket holding the lock at that moment had its restored target undone. The buckets rewritten earlier in the same pass kept a target pointing at the removed peer whenever the remove's own cleanup had already walked past them. The undo now covers every bucket this pass rewrote, attempting all of them so one failure does not strand the rest. * fix(site-replication): keep replay running while an endpoint refresh is pending A pending endpoint refresh took the whole heavyweight pass with it, so a peer that never came back froze IAM and bucket replay to every healthy peer too - the stall this journal's resume path was meant to end. The refresh arm now drains the retry queue before returning; it replays per-peer deliveries against the endpoints currently committed in state, so it is unaffected by the edit in flight. Bucket wiring reconciliation still waits, because it rewrites the very targets the refresh is changing, and the runbook now says so. * test(e2e): cover the AND semantics of a two-tag replication filter The acceptance matrix only had a single-tag rule, which matches under both AND and OR semantics and therefore proved nothing about the filter this fix changed. It now also carries a two-tag `And` rule - the shape `mc replicate add --tags "k1=v1&k2=v2"` writes - and asserts that an object with one of the two tags is not admitted while an object with both is. No new test function, so the nightly selection digest is unchanged. * refactor(site-replication): fold the refresh state-change error into one constructor The endpoint-refresh work added three `s3_error!` invocation lines, which the s3s footprint ratchet is meant to prevent. Five copies of the same concurrent-change error now share one constructor, so the surface nets one line smaller than main; the baseline is retightened to match. * fix(site-replication): report a peer whose IAM snapshot waits for a repair An escalated snapshot entry records a deletion a snapshot cannot replay, so only a repair settles it and the marker must survive. Scheduling an import snapshot therefore leaves that peer's entry alone - and now says so, instead of returning success while nothing was scheduled for it. * docs(operations): state the group-status and escalation convergence limits Two boundaries the fixes in this branch make load-bearing: a membership change never carries an enable, so a group disabled on one site only has to be re-enabled there explicitly; and a peer holding an escalated IAM entry does not receive a scheduled snapshot, including the one a bulk import schedules, until a repair settles it. * fix(ci): bind performance runs to selected inputs (#7512) * fix(targets): reject trailing batch items (#7508) * test(scanner): preflight G09 evidence disk space Fail the Scanner/Heal G09 upgrade evidence runner before downloading or building when the validation host does not have enough free space for a full raw evidence pass. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: 唐小鸭 <tangtang1251@qq.com> Co-authored-by: Zhengchao An <anzhengchao@gmail.com> Co-authored-by: cui fliter <imcusg@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(scanner): respect cargo target dir in G09 runner (#7528) * fix(replication): close the GA blocker set from backlog#2366 (#7503) * fix(replication): close GA blockers from backlog#2366 Implements the P1 set from the pre-GA replication audit: - Replication rule tag filters now require every And.Tag to match, replacing the s3s OR semantics with a local AND matcher that fails closed on a malformed tag. - A replicated group membership change no longer writes the group status, so a membership update carrying the default Enabled status cannot silently re-enable a disabled group on the peer. - A successful IAM import schedules one collapsed full-IAM snapshot per remote peer instead of leaving the imported entities local-only. - A pending endpoint refresh is redriven by the heavyweight reconcile tick, carries its own ilm-expiry override, and no longer blocks a remove that drops every unacknowledged peer. - Site metrics expose local replication failure totals and rolling windows; node-level counters no longer report a constructed zero. - set/remove-remote-target notify peer metadata caches before returning, so a follow-up put-bucket-replication on another node sees the target. - Adds the site-replication operations runbook, a docs index, a replication support boundary section, and the Replication changelog section. * fix(site-replication): resume only a locally driven endpoint refresh The peer-side edit handler journals a pending endpoint refresh with an empty `remote_peers` map and commits it inside the same request through `apply_internal_peer_edit`. The reconcile tick could not tell that journal from the coordinator's own: with no required peers it reads as complete on sight, so the tick committed it with `edit_state` - losing the local-name sync - and cleared it under the request that owned it, whose commit then reported the refresh as changed and denied the coordinator the peer acknowledgement it was waiting for. Resume now runs only for a journal that carries the fan-out topology. A receiver's journal stays for the coordinator to redrive with the same refresh id, which is the path that already recovers it. * fix(site-replication): keep an explicit disabled group status on a snapshot Skipping the group-status write whenever an item carries members stopped a membership change from re-enabling a disabled group, but it also silenced the full-IAM snapshot, which always sends members together with the sender's real status. A peer that did not have the group yet created it through `GroupInfo::new` - enabled - so a bootstrap, a repair, or the snapshot an IAM import now schedules handed every member of a frozen group live access there. The madmin wire maps an unset `groupStatus` to Enabled, so only Enabled can be a default. Disabled is always explicit and is applied again. * fix(site-replication): schedule the import snapshot without recording a failure `import-iam` reused the failure-recording path to queue its full-IAM snapshot. That raises `retry_count` on every call, so three imports - the normal shape of a bulk migration done one archive at a time - escalated a healthy peer to `retryStats.failed` with the scheduling note shown as `lastError`, which is exactly the signal the runbook tells operators to repair. A full retry queue also turned a completed import into a 503. Scheduling now only ensures the collapsed entry exists, and a failure to schedule is logged instead of failing the request: the entities are already imported and the reconcile pass still closes the gap. * fix(admin): stop reporting replication failures as retries `retries` is the minio-go counter for redeliveries, and mc prints it as such. Filling it with the failure count claimed a redelivery that never happens: a failed object is not retried by an event today, it waits for the scanner heal pass. `errors` keeps the failure counters; `retries` stays zero until there is a real redelivery to count, and the runbook now says so. * perf(site-replication): aggregate failure windows without cloning bucket stats `site_metrics_snapshot` went through `get_all`, which clones every bucket's stats, and then scanned each target's sample deque twice. That deque is bounded only by the one-hour window, so an unreachable target under load - the case an operator polls this endpoint for - made every `mc admin replicate status` copy the whole backlog and hold the read lock against the failure path while doing it. It now folds under the read lock and takes both windows in one walk. The `max` against the serialized `last_minute` / `last_hour` snapshots is dropped: those are stamped onto per-bucket clones elsewhere and are always zero in this node-local cache. * fix(site-replication): reject a conflicting ilm-expiry override on a re-run The commit now reads the ilm-expiry override back out of the pending refresh journal, so a second edit that asks for a different value had it dropped while the request still reported success. Re-running without the flag keeps pinning the recorded value - that is the documented way to redrive a stuck refresh - but an explicit different value is now rejected instead of ignored. * fix(admin): do not fail a remote-target write on a peer reload error set/remove-remote-target propagated the… * feat: configure the console base path at build time (#7636) Embed RUSTFS_CONSOLE_BASE_PATH into console routes, browser redirects, and startup URLs so OEM builds can use their own namespace. Preserve the default for an unset or empty build variable and keep route tests prefix-aware. * chore(release): prepare 1.0.0-rc.6 (#7641) * chore(release): prepare 1.0.0-rc.6 * ci: run offline enrollment boundary checks independently * fix(heal): preserve retryable batch failures during recovery (#7642) * fix(heal): preserve retryable batch failures during recovery * test(heal): pin prebuilt hooks binaries in ci * fix(s3): reject oversize single PUT early and map body errors to 4xx (#7635) * fix(s3): reject oversize single PUT early and map body errors to 4xx A single PutObject above the 5 GiB single-request ceiling was only rejected after the client had streamed 5 GiB into s3s's read-time body budget, and the resulting BodySizeLimitExceeded surfaced from the erasure writer as 500 InternalError. A body whose connection hit EOF before Content-Length bytes arrived (hyper's IncompleteBody) was also a 500. SDKs retry 500s, so one oversize upload was resent from offset 0 five times. - PutObject and UploadPart reject a declared length above MAX_SINGLE_PUT_OBJECT_SIZE with 400 EntityTooLarge before reading the body; the constant moves to rustfs_config so the s3s limit and the admission check share one value. - ApiError maps BodySizeLimitExceeded to EntityTooLarge and a hyper body EOF to IncompleteBody across both io::Error conversions. Fixes #7596. * test(s3): cover UploadPart admission, aws-chunked length, real s3s limit - Poll-counting test body proves PutObject and UploadPart reject a declared size above the ceiling with zero body polls; exact-cap and zero-length parts pass admission. - A STREAMING-* aws-chunked PUT whose framed Content-Length exceeds the cap is admitted when the decoded length is within it and rejected when the decoded length is over it. - The display-based BodySizeLimitExceeded matcher is checked against the real error produced by the pinned s3s Body budget. * fix(ecstore): make directory mtime fixture portable (#7623) * fix(ecstore): make directory mtime fixture portable * style(ecstore): format mtime fixture assertion --------- Co-authored-by: houseme <housemecn@gmail.com> Co-authored-by: Zhengchao An <anzhengchao@gmail.com> * fix(storage): prevent readiness after native migration failures (#7652) * fix(storage): prevent readiness after native migration failures * fix(storage): skip unsupported IAM records before reading * fix(storage): use stable typed migration metadata errors * fix(storage): include migration record in startup errors * test(storage): cover native migration startup failures * test(storage): use array chunks in migration fixture --------- Co-authored-by: RJ Regenold <214054+rjregenold@users.noreply.github.com> Co-authored-by: cxymds <cxymds@gmail.com> * fix(admin): expose OIDC account display fields (#7654) Expose verified OIDC username and email claims as display-only metadata on self-account responses while preserving the virtual parent as the authorization identity.\n\nKeep rustfs-madmin public response structs unchanged by adding the optional wire fields through private handler response wrappers. * fix(replication): correct peer joins and remote-state reporting (#7650) * fix(replication): propagate verified peer deployment identities * fix(replication): report actual remote peer state * fix(replication): defer initial sync until all peers join * test(replication): shut down TLS fixtures cleanly --------- Co-authored-by: houseme <housemecn@gmail.com> * feat(ci): add fault-tolerance degradation suite to the functional chain (#7663) Adds a fault-tolerance suite that verifies read/write behavior under drive and node loss against the erasure-coding contract and snapshots health-endpoint responses at every degradation tier. Scenarios derived from product source (default_parity_count, erasure set sizing): - A: single-node 4 drives (EC:2, read quorum 2): hide 1/2/3 drives - B: multi-node 4x1 (one set of 4, EC:2): stop 1/2/3 nodes - C: multi-node 4x4 (one set of 16, EC:4, read quorum 12): 1 node down lands exactly on the read-quorum boundary; 2 nodes down breaks it - C2: multi-node 4x4 with RUSTFS_STORAGE_CLASS_STANDARD=EC:8 (read quorum 8, write quorum 9, lock majority 9): 2 nodes down puts reads inside the reported divergence window (read quorum met while the lock majority is broken) By default a reads-refused-despite-met-read-quorum observation is reported as known-divergence without failing the suite; the strict input escalates it. Chain order becomes: upgrade -> s3 -> kms -> tier -> storage -> heal -> pool -> security -> replication -> fault-tolerance -> performance. * fix(ci): repair functional defaults and chain regression checks (#7664) * fix(ci): default functional suites to nightly packages * test(ci): follow the fault-tolerance chain handoff * "feat(ci): add fault-tolerance degradation suite to the functional chain" (#7667) Revert "feat(ci): add fault-tolerance degradation suite to the functional chain (#7663)" This reverts commit 7c47c48e85. * fix(ci): align security workflow tests with chain (#7679) * test(kms): cover non-default Vault Transit paths (#7657) * test(kms): cover custom Vault Transit metadata locations * test(kms): include a non-default Transit mount in live coverage * test(ecstore): tolerate cleanup quorum transition * test(ci): restore ten-suite chain expectations * test(ecstore): tolerate cleanup quorum transition in both causal polls The unversioned duplicate-delete poll in batch_transitioned_delete_uses_free_version_per_item reads exact metadata while the same asynchronous free-version cleanup removes per-disk copies, so it can hit the same transient InsufficientReadQuorum as the versioned poll. Share one helper between both polls; every other error still fails immediately. --------- Co-authored-by: overtrue <anzhengchao@gmail.com> * fix(s3): bound stalled UploadPart request bodies (#7659) * fix(s3): bound stalled UploadPart request bodies * fix(ci): preserve the S3S footprint ratchet * fix: enforce S3 permissions for recursive force deletion (#7661) * fix: enforce S3 authorization for recursive deletion * fix: satisfy the s3s footprint guard * fix: restore list versions policy compatibility (#7686) * fix(tables): reject reserved warehouse locations (#7671) Co-authored-by: cxymds <cxymds@gmail.com> * fix(e2e): require a verified server binary for every e2e run (#7687) * fix(ci): share quick checks and lint workflows * fix(ci): install actionlint from its verified release * fix(ci): reject dependencies on required quick checks * feat(test): verify the E2E server build and source identity * test(e2e): register verified Darwin test membership * test(e2e): record verified Linux receipt test membership * test(e2e): record compiled Darwin receipt test membership * test(e2e): record compiled Linux receipt test membership * test(e2e): record Darwin e2e-full membership after merging main * fix(test): route scanner/heal evidence E2E runs through the verified server binary The evidence runners built rustfs with plain cargo and then ran e2e_test directly, which now fails without a run receipt. They build through scripts/e2e_binary.py and run the e2e_test invocations under e2e_binary.py run; the obsolete rustfs.features stamp is removed. * docs(e2e): run server-backed e2e commands through the verified binary wrapper * test(e2e): record Linux e2e-full membership from the branch CI listing * fix(ci): bind nightly lanes to one resolved source (#7688) * feat(ci): measure queue and execution time by run attempt (#7689) * feat(ci): measure queue and execution time by run attempt * fix(ci): bound timing samples and recognize the old workspace lane * fix(ci): sample completed runs for stable timing comparisons * fix(ci): verify complete functional chain evidence (#7690) * fix(ci): bind nightly lanes to one resolved source * fix(ci): verify complete functional chain evidence * fix(kms): classify KMS/SSE error contracts and SSE-S3 headers (#7697) * fix(sse): classify bare SSE-KMS writes when no KMS is available A `aws:kms` request without a key id, on a bucket without a default key, returned `500 InternalError` whenever no KMS service was running: the "no KMS key available" branch exited with an untyped storage error before the availability classification that the keyed form already received. Route that branch through the same split: `503 ServiceUnavailable` while a configured KMS is stopped, `400 InvalidRequest` when KMS was never configured, and `400 InvalidRequest` naming the missing key id when a running KMS has no default key. `CreateMultipartUpload` shares the path. Adds a unit test for the bare form and an e2e module that stops KMS through the admin API, runs a master-key-only node, and runs a Local KMS without a default key; refreshes the e2e-full selection digests. (cherry picked from commit c3259dadc3d603a9185a5b0ad9f83dfb884e61c8) * fix(sse): keep KMS error classes on the encrypted read path GetObject, CopyObject and UploadPartCopy on an SSE-KMS object whose key no longer exists answered `500 InternalError` ("KMS key not found") while PutObject under the same key already answered `400 KMS.NotFoundException`. The read path carries its classification through ecstore's `EncryptionResolutionErrorKind`, which had no kind for a missing key, a denied KMS grant or a missing backend capability, so all three folded onto `DecryptionFailed` and the S3 layer reported an internal fault. Add `KeyNotFound`, `AccessDenied` and `NotImplemented` kinds, map them on both sides of the boundary, and give an envelope the configured backend cannot unwrap a diagnosable message while keeping its `500`. Unit tests cover the kind round trip and the reader wrapping; a new e2e test deletes a key immediately and checks GET/Copy return 400 with `KMS.NotFoundException` while HEAD stays 200. The e2e-full selection digests are refreshed from the current listing (the previous digests predated the delete-authorization tests) and the e2e `create_default_key` helper is updated to the accepted `EncryptDecrypt` spelling. (cherry picked from commit 2523a9814e97caea318d4ff1a51bef3a4d4445b2) * fix(kms): classify key-management errors on the admin routes `POST /kms/keys`, the legacy `create-key` alias and `generate-data-key` reported every backend refusal as `500`: a blank key name (which each backend failed on differently, the Local backend by writing a key file with an empty stem), a name already taken, an unknown key, a disabled key and a capability the backend lacks. `delete` and the lifecycle routes already classified the same errors. Refuse a blank or whitespace name in `KmsManager::create_key` before any backend sees it, and share one `KmsError` to status mapping across create, delete and generate-data-key (400 for validation and key state, 404 for an unknown key, 409 for a taken name, 501 for a missing capability, 500 only for damaged material). The XML-error routes carry the same status explicitly since s3s derives none for a custom code. The read-only Static backend now reports create, delete and cancel-deletion as `UnsupportedCapability`, matching its rotate and enable/disable answers, so the admin API returns 501 for all of them. (cherry picked from commit e33cac5493c4d9d6662e0d2980b58ba2b24a6d1b) * fix(sse): stop SSE-S3 responses from naming the wrapping KMS key `x-amz-server-side-encryption-aws-kms-key-id` is defined for `aws:kms` objects only, but PutObject, CopyObject, CreateMultipartUpload and GetObject returned it for `AES256` objects too, carrying the KMS key that wraps the SSE-S3 data key (the service default, or the literal `default` on a node without KMS). The write paths copied `kms_key_id` from the encryption material unconditionally, and the single-decrypt GET classification did the same after resolving the key for authorization. Add `EncryptionMaterial::response_kms_key_id`, which yields the id only for SSE-KMS, use it at the four write-response sites, and gate the GET classification the same way. CompleteMultipartUpload and HeadObject already omitted the header. Unit tests pin both directions; a new e2e test covers Put/Get/Head/Copy and CreateMultipartUpload for AES256 with an aws:kms control. The e2e-full selection digests are refreshed from the current listing. (cherry picked from commit 29d793a63352b0b60fd53c565e80fdbede8964bb) * fix(s3): validate PutBucketEncryption rules before storing them A default-encryption rule naming an unknown `SSEAlgorithm` (for example `AES128`), a rule without `ApplyServerSideEncryptionByDefault`, an empty rule list, or a `KMSMasterKeyID` on an `AES256` rule was stored as written: the only algorithm check on the route decided whether to fill in the default KMS key. `GetBucketEncryption` then advertised that configuration while the write path encrypted header-less writes under its `AES256` fallback, so the bucket's declared and actual schemes disagreed. Two comments claimed the route already refused unknown algorithms. Validate the configuration before any of it is applied: `MalformedXML` for a malformed rule set or unknown algorithm, `InvalidArgument` for a key id on a non-KMS rule, and nothing stored on refusal. Correct the two comments to describe when the AES256 fallback is still reachable. Unit tests cover every refusal and the accepted shapes; an e2e test checks the refusals leave the previous configuration in place. The e2e-full selection digests are refreshed from the current listing. (cherry picked from commit 29e4486dce41197ed93f5253cdbabc57d27a4ddb) * test(e2e): refresh e2e-full selection for the combined KMS/SSE fixes * test: align two unit tests with the new KMS and bucket-encryption contracts `scheduled_deletion_carries_a_deadline_and_can_be_cancelled` still expects the state error (`InvalidOperation`) for cancelling a key that is not pending deletion; only the Static backend's mutations moved to `UnsupportedCapability`. The uninitialized-store PutBucketEncryption test now sends a well-formed AES256 rule so it reaches the store lookup instead of the new configuration validation. * Collect bounded Connect environment inventory (#7710) feat(connect): collect environment inventory * Add Connect service license commands (#7711) feat: add Connect service license client * Add consent-bound diagnostic scheduling (#7713) feat(connect): schedule consent-bound diagnostics * feat(connect): advertise environment diagnostics (#7714) * feat(connect): add consent-bound profile exports (#7716) feat: add consent-bound profile exports * feat(connect): add bounded local log capture (#7718) * feat(connect): add bounded network performance producer (#7719) * Add bounded local telemetry export commands (#7720) feat(connect): add bounded telemetry producers * Add bounded drive performance command (#7721) feat(connect): add bounded drive performance producer * Add bounded top diagnostic captures (#7722) feat(connect): add bounded top diagnostic producers * Add client-to-deployment performance diagnostics (#7726) feat: add client performance diagnostics * Add a local environment inventory command (#7728) feat(connect): add local environment inventory command * feat(connect): add bounded object performance diagnostics (#7734) feat(connect): add object performance producer * Add authenticated inter-node network performance probes (#7739) * feat(connect): add authenticated inter-node network probes * fix(connect): respect storage facade boundary * fix(site-replication): keep an operator's bucket-level target to a peer instead of taking it over (#7709) * fix(site-replication): keep an operator's bucket-level target to a peer instead of taking it over Site replication wired each bucket by looking for an existing replication target "to the same peer" and rewriting the first match in place as its own same-name target. An operator's bucket-level target that happened to point at that site (different target bucket, operator credentials) was the first match whenever it pre-dated the join, and the reconciler repeats the pass every 600s, so the takeover also depended on target order afterwards. The operator's rule then named an ARN no target backed and their bucket replication stopped silently, while the inherited bucket-level reset id made every site resync report the bucket as owned by another resync (rustfs/backlog#2479, rustfs/backlog#2489). Follow MinIO's `getRemoteARN` / `getRemoteARNForPeer` shape instead: - Wiring updates a target in place only under the same ARN, or when it is recognisably the site's own under an older ARN shape (same peer, same-name target bucket, site replication service account). Anything else gets the site target added next to it. - The site resync manifest takes the target the derived `site-repl-<deployment id>` rule names (same-name shape as fallback), so an operator target to the peer neither aborts the bucket as "multiple remote targets matched peer" nor gets resynced into. - Peer removal prunes only targets a pruned derived rule names or the same-name target bucket; operator targets stamped with the peer's deployment id survive together with their rules. Unit tests cover the three predicates. e2e `test_site_replication_keeps_operator_bucket_target_to_peer` runs a bucket-level replication plus `replication-reset` to the future peer, joins the sites, and requires the operator target untouched, both paths delivering, the site resync completing against the site target, and the operator target and rule surviving `replicate remove --all`; without the fix it fails at the join with the operator target gone. The repl-nightly selection digest is refreshed for the new case. * test(site-replication): drop a redundant clone flagged by clippy The reconcile unit test cloned the remote peer into the state map although the binding is not used afterwards; workspace clippy (-D warnings) rejects that as redundant_clone. * chore(deps): update flake.lock (#7733) * chore(deps): update flake.lock Flake lock file updates: • Updated input 'nixpkgs': 'github:NixOS/nixpkgs/17de0b9' (2026-09-04) → 'github:NixOS/nixpkgs/aff8a0b' (2026-09-10) • Updated input 'rust-overlay': 'github:oxalica/rust-overlay/c361047' (2026-09-05) → 'github:oxalica/rust-overlay/228ecef' (2026-09-12) * fix: satisfy Rust 1.98 clippy lints Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * chore(deps): update flake.lock (#7733) * chore(deps): update flake.lock Flake lock file updates: • Updated input 'nixpkgs': 'github:NixOS/nixpkgs/17de0b9' (2026-09-04) → 'github:NixOS/nixpkgs/aff8a0b' (2026-09-10) • Updated input 'rust-overlay': 'github:oxalica/rust-overlay/c361047' (2026-09-05) → 'github:oxalica/rust-overlay/228ecef' (2026-09-12) * fix: satisfy Rust 1.98 clippy lints Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * feat(connect): support explicit enterprise proxies (#7745) feat(connect): add explicit proxy transport * feat(connect): emit drive unavailable log events (#7747) * feat(connect): add local inspect export producer (#7750) * feat(connect): add local inspect export producer * fix(connect): use the storage inspection facade * test(connect): cover nested allocator profile stats (#7717) * test(connect): cover nested allocator profile stats * test(connect): use async profile test lock * test(security): allow synthetic redaction fixture --------- Co-authored-by: Hauser <housemecn@gmail.com> * docs(security): add presigned copy advisory lesson (#7754) * fix(ecstore): refuse RMW and reads of unreadable bucket configs (#7759) An XML bucket sub-config whose stored bytes cannot be parsed was still folded into "absent" on two paths: update_config_with handed it to mutate, which rebuilt it from nothing and overwrote the only copy of the bytes, and the tagging/lifecycle/CORS/website/logging/accelerate/request-payment getters reported ConfigNotFound. Add an explicit ConfigState (Absent / Valid / Unreadable) over the existing retained parse failure, refuse the read-modify-write of an unreadable target config before mutate runs (per config, other configs stay writable), and make those getters fail closed. GetBucketLifecycle now only maps ConfigNotFound to NoSuchLifecycleConfiguration. The Swift tagging rewrite recognizes the refusal by type instead of a string sentinel. Refs rustfs/backlog#1734 * refactor(filemeta): own persisted metadata key authority (#7760) Add rustfs_filemeta::metadata_keys as the single source of the nine xl.meta meta_user keys, byte-identical to current literals, and migrate filemeta consumers off s3s::header and rustfs_utils header constants. Pin the literals, cross-check historical sources, and prove old xl.meta bytes still decode via a captured fixture and a per-character mutation sweep. Refs rustfs/backlog#1735 * Sync network performance protocol fixtures (#7761) test(connect): sync diagnostic protocol fixtures * Sync site replication result fixtures (#7762) test(protocol): sync site replication result fixtures * Sync telemetry producer fixtures (#7763) test(protocol): sync telemetry producer vectors * refactor(rio): own trailer source and drop s3s dependency (#7764) Move the aws-chunked trailing checksum handle behind a RustFS-owned rustfs_rio::TrailerSource (Pending/Missing/Present lookup with a documented EOF timing contract) and adapt s3s::TrailingHeaders once in the application crate. rio no longer depends on s3s; behaviour is unchanged. Refs rustfs/backlog#1735 * Deliver diagnostic scheduler receipts to Connect (#7767) feat(connect): deliver diagnostic scheduler receipts * fix(ecstore): refuse writes on unreadable bucket configs with 503 (#7768) Close the remaining paths where a stored bucket sub-configuration whose bytes cannot be parsed still read as absent (rustfs/backlog#1734, slice 2): - Object writes resolve versioning through BucketVersioningSys::get_for_write; RUSTFS_BUCKET_CONFIG_PARSE_MODE=strict refuses them, the default permissive mode keeps the historical unversioned write and records it. - Versioning, Object Lock, encryption, public access block and notification getters and the delete-time versioning check return the typed UnreadableBucketConfig refusal, which ApiError maps to 503 naming the bucket, config and stored length. StorageError::clone keeps it typed. - Object Lock checks stay on when the lock config is unreadable. - Notification setup isolates an unreadable config to its bucket instead of clearing its rules; GetBucketNotificationConfiguration reports it. - Add rustfs_bucket_metadata_parse_failed_total and rustfs_bucket_metadata_unparsable_current, an invalid-mode startup check, and the s3gate-parse-strict compat register entry. * feat(connect): add site replication performance producer (#7769) feat(connect): add site replication performance core * refactor(ecstore): read persisted object-metadata keys from the filemeta authority (A3b) (#7770) Migrate ecstore and rustfs-lifecycle consumers of the persisted xl.meta meta_user keys (object lock, restore, replication status, storage class, SSE read) from s3s::header / rustfs_utils header constants to rustfs_filemeta::metadata_keys. HTTP header production is unchanged and every lookup keeps its previous exact / case-insensitive mode. - SSE key: persisted only as lowercase; the mixed-case spelling is outbound replication user metadata. Keep the case-insensitive read and pin it against the pre-A3a fixture. - warm tier: strip promoted keys case-insensitively so the persisted X-Amz-Replication-Status is no longer forwarded to the tier. - fix stale HashReader::add_checksum_from_s3s call in ecstore tests. Refs rustfs/backlog#1735 * feat(connect): add device license renewal client (#7771) * feat(connect): add approved artifact relay (#7772) feat(connect): add approved artifact relay core * fix(connect): export relay CLI types (#7773) * feat(connect): add device report upload client (#7774) * feat(connect): add typed telemetry trace source (#7775) * fix(connect): avoid shadowing replication URL helper (#7777) * fix(connect): restore site replication test nonce (#7778) * fix(connect): restore rustfs build after site replication perf producer (#7779) #7769 left rustfs/src/connect/diagnostics/perf_site_replication.rs failing to compile: a local binding named object_url shadowed the object_url() helper in the same scope (E0618), and a test put the consent nonce on the request instead of LocalSiteReplicationConsent (E0063/E0560). Rename the binding to source_url and move the test nonce into the consent. * fix(rustfs): restore test compilation (#7780) * feat(connect): sign site replication target pair (#7781) * refactor(filemeta): own RestoreStatus and drop the s3s dependency (A3c) (#7782) Replace s3s::dto::{RestoreStatus, Timestamp} in filemeta with a filemeta-owned RestoreStatus (same field names, OffsetDateTime expiry). RestoreStatusOps and parse_restore_obj_status keep their signatures and persisted rendering; the ecstore restore finalize / lifecycle restore writers and rustfs RestoreObject now build the filemeta type. - crates/filemeta: drop s3s; tokio "time" becomes a dev-dependency (the metacache tests got it through s3s feature unification). - metadata_keys: drop the s3s half of the historical-source cross-check; PINNED, the pre-A3a fixture and per-character mutation still pin keys. - new test re-renders the pre-A3a fixture restore value byte-for-byte. - s3s footprint baselines 210 -> 209 files, ecstore 37 -> 36. Refs rustfs/backlog#1735 * feat(connect): add service license relay import (#7784) * feat(admin): add a gateway key inventory for the S3 stack switch (#7785) GET /rustfs/admin/v3/gateway-key-inventory (admin:InspectData) lists every stored object key the RustFS S3 gateway would refuse on every operation, so an operator can copy those objects to a safe key before switching stacks. The rules mirror the gateway key floor; . and .. segments never appear because ecstore refuses them on every write. Refs rustfs/gateway#754 * feat(server): add RUSTFS_S3_STACK with a gateway GetBucketLocation path (#7786) * fix(connect): restore the site replication producer build The producer shadowed its object_url helper with a local of the same name, and its test placed the consent nonce on the request, so neither the rustfs library nor its tests compiled on main. * feat(server): add RUSTFS_S3_STACK with a gateway GetBucketLocation path RUSTFS_S3_STACK=legacy (default) keeps the s3s service as the whole S3 entry. RUSTFS_S3_STACK=gateway routes GetBucketLocation through the RustFS Gateway pipeline pinned at rustfs/gateway@90b83a20 and falls back to the same s3s service for every other request, decided before the body is read. Refs rustfs/backlog#1752. * revert: remove M1 gateway git dependency until CI can access rustfs/gateway (#7787) Revert "feat(server): add RUSTFS_S3_STACK with a gateway GetBucketLocation path (#7786)" This reverts commit b5c2e1da90. * fix: retry IAM migration quorum failures on startup (#7788) * fix: retry interrupted uploads through proxies (#7789) fix: retry proxied upload interruptions * fix(connect): capture telemetry from server runtime (#7790) * fix: classify explicit proxy failures (#7791) * fix: skip IAM migration when legacy volume is absent (#7792) * fix(release): include CLI in Linux artifacts (#7794) * fix(release): serialize Linux binary links (#7797) * feat(connect): expose live lock count snapshots (#7801) * feat(connect): capture live API activity (#7804) * feat(connect): collect native Linux thread states (#7806) Collect bounded aggregate thread states from Linux procfs while preserving explicit unsupported outcomes for unavailable scopes. * feat(connect): capture live RPC activity (#7807) * test(connect): verify top.disk release artifacts (#7808) * test(connect): require native top.disk runner (#7809) * feat(connect): capture bounded local CPU profiles (#7811) * ci: retain top disk acceptance archive (#7812) * fix(connect): observe host traffic in top net (#7814) * ci: enable CPU profiling in supported release builds (#7815) * test(connect): verify profile cpu release artifacts (#7818) * test(connect): retain CPU profile verification key (#7819) * test(connect): retain CPU profile import bundle (#7820) * feat(connect): expose object inspect CLI (#7821) * feat(connect): wrap diagnostic reports for upload (#7822) * fix(connect): parse inspect paths as paths (#7826) * feat(connect): verify typed diagnostic jobs (#7827) * fix(connect): accept KMS report upload authorization (#7828) * Run signed diagnostic jobs in the RustFS service (#7829) feat(connect): run diagnostic jobs in service * fix(connect): emit canonical report manifest time (#7830) * Upload diagnostic job results through support bundles (#7831) feat(connect): upload diagnostic job results * fix(connect): emit canonical top envelope time (#7836) * fix(connect): publish diagnostic producer capabilities (#7837) * fix(io-metrics): drop the rustfs-common edge by injecting the S3 telemetry observer (#7795) * fix(io-metrics): drop the rustfs-common edge by injecting the S3 telemetry observer dc700d366 (#7775) made the io-metrics leaf crate depend on rustfs-common to publish typed telemetry trace events from S3HttpRequestGuard, which breaks the backlog#1834 leaf-crate rule (io-metrics may only depend on rustfs-s3-ops). S3HttpRequestGuard now takes an optional fn-pointer completion observer (operation, latency, 2xx?) and knows nothing about the trace bus. The server builds guards through rustfs::server::s3_http_request_guard, which attaches the observer only while a telemetry subscriber exists and owns the S3Operation -> TelemetryTraceOperation mapping. * chore(guard): admit #7785 s3s ratchet growth (+1 file, +4 lines) #7785 landed the gateway key inventory admin handler after the baselines were verified, leaving check_s3s_footprint.sh red on main and every branch cut from it (measured 210 files / 1592 lines vs 209/1588 baselines). The handler follows the house admin convention whose Operation::call signature is s3s-typed (S3Request/S3Result), so it cannot route through a non-s3s seam until the s3gate admin migration replaces the admin router (rustfs/backlog#1677 F1); no local refactor can shed the file-level import. Record the measured growth with rationale: files 209 -> 210, s3_error! lines 1588 -> 1592. * fix * fix: resolve clippy gate failures in connect and CLI surfaces - Box the two large CommandResult performance variants and LicenseRenewalOutcome::Installed (clippy::large_enum_variant) - Return RelayError instead of () from RelayTransport::deliver and the test destination (clippy::result_unit_err) - Drop an unused mut on the protected relay file handle (unused_mut) - Pass the digest by value to base64 encoding and drop a redundant result_json clone (clippy::needless_borrows_for_generic_args, clippy::redundant_clone) * fix(connect): resolve the remaining site-replication clippy errors - Group the endpoint credential triple into SiteReplicationCredentials so SiteReplicationEndpoint::new takes 6 arguments (clippy::too_many_arguments) - Take the build-feature validator by &str (clippy::ptr_arg); the validator closure stays because &String needs the deref coercion * style: apply rustfmt to the site-replication credential grouping * fix(connect): keep the CPU profile fixture off the ecstore import scan #7811 used "rustfs_ecstore::disk::read_object" as the raw-symbol fixture of the profile redaction test, which the architecture guard counts as a direct rustfs_ecstore reference outside the compatibility boundaries (its scan deliberately includes inline test modules). The accumulator treats symbols opaquely, so use the internal rustfs::storage:: path that keeps the fixture realistic without matching the import scanner. * fix * fix * fix * fix --------- Co-authored-by: Hauser <housemecn@gmail.com> * fix(replication): count a bodiless 405 as a replicated delete marker (#7756) * fix(replication): accept a bodiless 405 as a replicated delete marker during resync A resync verifies each delete marker with `HEAD ?versionId=<marker>` on the target. S3 targets (RustFS, MinIO, AWS) answer that with 405 and no body, and the SDK only synthesizes an error code for 404, so the error arrived with `code() == None`. `is_retryable_delete_replication_head_error` then treated it as an ambiguous failure: every delete marker counted as a failed object with `target service error`, and a site resync over any bucket that holds a delete marker reported the whole bucket as failed (rustfs/backlog#2479, SITE-105 on rc.6 and nightly). Use the raw HTTP status the way the 404 path already does: a 405 without a code confirms the marker propagated. Ambiguous statuses still fail. - Unit tests drive `verify_resync_head_result` against a scripted target answering 405 (accepted) and 503 (still failed). - e2e `test_site_replication_resync_replicates_delete_marker` joins two sites, converges a live object and a delete marker, and requires the site resync to complete with zero failed objects; the repl-nightly selection digest is refreshed for the new case. * fix(replication): verify marker-version purges by absence during resync A delete-marker resync entry with a pending or failed version purge asks the target to remove the marker, so the bodiless 405 that proves a created marker propagated proves the purge did not happen. Accept the 405-as-success mapping only for marker creation (empty version_purge_status); a purge counts as replicated only when the target answers not found, and any other HEAD outcome stays failed. Unit tests drive both purge statuses against the 405 fixture and the 404 fixture. * fix(kms): refuse key ids that leave the key prefix on the Vault backends (#7727) Only the Local backend refused a key identifier containing a path separator. On Vault KV2 a create with the name bad/name succeeded and produced a nested KV2 path that the listing then reported as a directory rather than a key, and an identifier containing .. addressed a record outside the configured key prefix once the HTTP client normalised the URL; Vault Transit built its transit key name and its metadata path from the same unchecked identifier. Lift the Local backend's containment rule into a shared segment check (empty, /, backslash, NUL, . and ..) and apply it at the single point where each backend turns the identifier into a path or a Transit key name, so create, describe, encrypt, delete and the metadata writes all refuse with InvalidKey before any request reaches Vault. The admin API already maps that to 400. The AWS backend is untouched: it addresses keys by ARN and alias, both of which contain /. Refs rustfs/backlog#2474 (KMS-213 CreateNegatives on vault-kv2). Co-authored-by: Hauser <housemecn@gmail.com> * Preserve safe profile job failure reasons (#7860) fix(connect): preserve safe profile job failure reasons * Freeze the heartbeat producer capability registry (#7861) test(connect): freeze heartbeat producer capabilities * fix: resume GET body after peer short EOF (#7852) * fix: resume get body after short eof Treat mid-stream short EOF errors as resumable when the S3 GET body has an attached resume context. This lets peer-kill reads reopen the same object version at the emitted offset instead of aborting the 200 response body. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * fix(connect): surface TLS peer bootstrap failures Map Connect registration TLS peer validation failures to the dedicated bootstrap error so wrong CA inputs fail closed with the sanitized TLS variant instead of the generic exchange error. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * ci: file scheduled-failure issues in rustfs/backlog (#7847) Scheduled pipeline failures currently open [scheduled-failure] tracking issues in rustfs/rustfs itself, adding bot noise to the code repository's issue tracker. Route that alerting to rustfs/backlog instead. - schedule-failure-issue gains target-repository (default rustfs/backlog); dedupe lookup, comment appends and issue creation target that repository. - New source-token input (default ${{ github.token }}) reads the failed-job list from the reported run; the run still lives in and links to rustfs/rustfs. The issue body now carries a '- Repository:' line. - All consumer workflows pass secrets.BACKLOG_ISSUE_TOKEN; the workflow-scoped GITHUB_TOKEN cannot open issues cross-repo. Alert job permissions blocks are unchanged. * fix(admin): keep the gateway key inventory off the s3s surface (#7817) The gateway key inventory handler added in #7785 imported s3s directly and built four errors with s3_error!, pushing the s3s footprint ratchet to 210 files and 1592 s3_error! lines on main. Route its S3 types and error construction through the crate::admin::storage_api::s3 facade like sibling admin handlers; the codes, HTTP statuses and messages are unchanged, and a new unit test pins them. Co-authored-by: cxymds <cxymds@gmail.com> Co-authored-by: Hauser <housemecn@gmail.com> * fix(s3): honor presigned UploadPart checksum queries (#7748) * fix(s3): honor presigned UploadPart checksum queries * fix(s3): keep checksum errors within gateway boundary --------- Co-authored-by: Hauser <housemecn@gmail.com> * fix(auth): reject unsigned x-amz headers on header-signed SigV4 requests (#7796) * fix(auth): reject unsigned x-amz headers on header-signed SigV4 requests A SigV4 request authenticated with an Authorization header only binds the headers named in its SignedHeaders list, but RustFS acted on every x-amz-* header that arrived, so a replayed header-signed PutObject carrying an unsigned x-amz-copy-source became a CopyObject run as the signer that could copy any object the signer can read (GHSA-xm99-m3gq-83g8). The presigned form was already closed by GHSA-g8w9-qw9q-fghr. reject_unsigned_amz_headers_on_sigv4_request now guards S3Access::check and S3Router::check_access: every SigV4 signed-header list the request carries must cover every x-amz-* header, the Authorization header is parsed with the verifier's own s3s-sigv4 parser and compared case-insensitively, the algorithm token is pinned to AWS4-HMAC-SHA256 because the upstream header path accepts any token, and the exempt set mirrors the upstream s3s fix (x-amz-content-sha256, x-amz-decoded-content-length, x-amz-trailer, x-amz-checksum-algorithm) plus x-amz-cf-id. Adds ghsa_xm99 unit, router and e2e regressions, raises the security smoke floor to 28, and records the advisory in docs/testing/security-regressions.md and CHANGELOG.md. * chore(deps): switch s3s and s3s-sigv4 to crates.io 0.16.0 * fix(server): enforce the SigV4 header guard ahead of s3s dispatch s3s 0.16 verifies the claimed algorithm as the first step of its own signature flow, so a request whose Authorization header swaps the AWS4-HMAC-SHA256 token was answered with 501 NotImplemented before RustFS's access layer could rule on the unsigned x-amz-copy-source (GHSA-xm99-m3gq-83g8). Add the SigV4HeaderGuardLayer as the innermost external stack layer, running reject_unsigned_amz_headers_on_sigv4_request in front of s3s and serializing its rejections as the same AccessDenied S3 error document the access layer produces. --------- Co-authored-by: Hauser <housemecn@gmail.com> * fix(table-catalog): map transient lock failures to unavailable (#7841) * Verify profile service jobs on native Linux (#7862) ci: verify profile service jobs on native Linux * Authorize the private Connect acceptance checkout (#7863) ci: authorize private Connect harness checkout * Run profile service acceptance directly (#7864) ci: run profile service acceptance directly * Retain profile service failure evidence (#7868) ci: retain profile service failure evidence * fix: update dependencies and preserve transport errors (#7798) * chore(deps): bump ed25519-dalek in the dependencies group Bumps the dependencies group with 1 update: [ed25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek). Updates `ed25519-dalek` from 2.2.0 to 3.0.0 - [Release notes](https://github.com/dalek-cryptography/curve25519-dalek/releases) - [Changelog](https://github.com/dalek-cryptography/curve25519-dalek/blob/3.0.0/CHANGELOG.md) - [Commits](https://github.com/dalek-cryptography/curve25519-dalek/compare/ed25519-2.2.0...3.0.0) --- updated-dependencies: - dependency-name: ed25519-dalek dependency-version: 3.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dependencies ... Signed-off-by: dependabot[bot] <support@github.com> * chore(deps): bump jiff, aws-sdk-s3, datafusion and smallvec Bump the dependencies group: - jiff 0.2.35 -> 0.2.37 - aws-sdk-s3 1.146.0 -> 1.146.1 - datafusion 55.0.0 -> 55.1.0 - smallvec 1.16.0 -> 1.16.1 Update Cargo.lock for the matching transitive bumps (datafusion subcrates, hickory, cc, crc32fast, tinyvec, toml_edit and others); tinyvec_macros is no longer required. * chore(deps): use s3s 0.16.0 release and bump rust-version to 1.98.1 * fix: preserve ready reader errors during erasure write failures When erasure writers fail after the producer has already surfaced a reader error, return the reader error instead of aborting the producer and masking it with the write-side failure. This keeps UploadPart body read timeouts classified as RequestTimeout under loaded pipeline timing. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * test: use current checksum API in multipart regressions * fix: stabilize connect dependency update tests Classify Connect proxy failures only when an explicit proxy is configured, preserve TLS classification across request error shapes, keep short object performance windows from spending too much budget on cleanup, and update multipart checksum tests for the current HashReader API. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Hauser <housemecn@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Hauser <housemecn@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com> Co-authored-by: overtrue <anzhengchao@gmail.com> * ci: expect BACKLOG_ISSUE_TOKEN in scheduled alert wiring checks (#7867) #7847 routed schedule-failure alerting to rustfs/backlog by switching the alert jobs' token to secrets.BACKLOG_ISSUE_TOKEN, but check_test_wiring.py still asserts the literal 'github-token: ${{ secrets.GITHUB_TOKEN }}', so Quick Checks fails on every open PR. Update the wiring assertions and the self-test fixtures to the new literal. Both `--self-test` (52 tests) and the full `validate()` pass locally. * Pace diagnostic job result redelivery (#7869) fix(connect): pace diagnostic result redelivery * Execute authenticated top.api service jobs (#7872) feat(connect): execute top.api service jobs * feat(connect): execute top.locks service jobs (#7874) * fix(ci): gate Connect acceptance on x86 build job (#7875) * fix(ci): repair E2E inventory and network CLI coverage (#7871) * ci: refresh Linux full E2E inventory after SigV4 tests * test(connect): drive traffic for top net CLI export coverage * feat(connect): execute performance network jobs (#7877) * feat(connect): execute bounded drive performance jobs (#7878) * Preserve the top API service job nonce (#7879) fix(connect): preserve top api job nonce * feat(connect): execute thread profile service jobs (#7880) * Execute authenticated top.rpc service jobs (#7881) feat(connect): execute top.rpc service jobs * ci: add service diagnostic acceptance workflows (#7882) * ci: add threads and RPC acceptance workflows (#7883) * fix(connect): deliver diagnostic results until expiry (#7886) * feat(connect): export signed environment inventory (#7887) feat: export signed environment inventory * fix: recover interrupted GETs and heal operations (#7876) * fix(heal): retry interrupted internode shard writes * fix(deps): update rustls for RUSTSEC-2026-0285 * fix(heal): retain RPC transport failures across metadata probes * test(heal): wait for replacement disk and coordinator readiness * test(connect): validate service-only diagnostic capabilities * fix(s3): resume GET bodies after erasure read quorum loss * fix: keep top locks within its capture window (#7888) * fix: recover heal after peer boot epoch changes (#7889) * test(heal): keep outage objects in the replacement erasure set * fix(rpc): retry authenticated requests after peer epoch changes * test(rpc): assert retryable rejection of stale boot epochs * ci: bound concurrent heal clusters in the full E2E gate * ci: register the table suite workflow on the default branch (#7893) * ci: register the table suite workflow on the default branch The table suite workflow (#7873) only exists on release so far, and GitHub registers workflow_dispatch targets exclusively from the default branch — the suite cannot be triggered until this file lands on main (same mechanism that keeps the fault-tolerance suite undispatchable). This adds the identical rustfs-table-test.yml (byte-for-byte the release version) plus the contract-test registration (JOBS / DIRECT_TESTS / upload allowlist), and nothing else from release. * ci: pin actions in the table workflow to full commit SHAs The default branch enforces check_workflow_pins.sh (unpinned third-party action refs fail CI). Use the same pinned SHAs as the other suite workflows on main: actions/checkout@9c091bb... (#v7) and actions/upload-artifact@b7c566a... (#v6). Note: the release copy of this workflow still uses @v4 tags; release does not run the pin gate. Release and main will converge on the pinned form during the full sync. * test(ecstore): synchronize causal cleanup observations (#7894) * fix(ecstore): create markers for repeated versioned deletes (#7884) Co-authored-by: cxymds <cxymds@gmail.com> * Preserve top.locks signed job nonce (#7898) fix(connect): preserve top locks job nonce * fix(ecstore): roll back failed delete marker writes (#7899) * chore(deps): refresh RustFS tokio tar dependency (#7907) * chore(deps): refresh RustFS tokio tar dependency Switch the astral-tokio-tar workspace alias to the released rustfs-tokio-tar 0.7.1 crate and remove the obsolete cargo-deny git source allowance. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * chore(deps): align AWS smithy dependency family Upgrade the AWS SDK and smithy crates together while patching aws-smithy-json 0.63.0 for the aws-smithy-types 1.7.0 DocumentObject API used by aws-config 1.12.0. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * revert(deps): use official AWS smithy compatible set Remove the local aws-smithy-json patch and roll the AWS smithy family back to the latest official combination that compiles with aws-config 1.12.0. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * docs(architecture): retire tokio tar cleanup entry Remove the stale cleanup-register entry after switching back to the released rustfs-tokio-tar crate, leaving no unmatched compatibility marker for the architecture guard. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * ci: restore table workflow failure contract Align the table functional workflow with the quick-check guard by letting suite failures stay red, generating PASS reports only from complete successful evidence, and preserving the shared backlog issue fallback for harness failures. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * fix(deps): expose rustfs tokio tar dependency name Use the published rustfs-tokio-tar dependency key throughout the workspace while keeping source imports on the crate's tokio_tar lib target name. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com> * fix(ci): retain failed functional chain reports and check runners (#7906) --------- Signed-off-by: houseme <housemecn@gmail.com> Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Hauser <housemecn@gmail.com> Co-authored-by: hector <42570491+majinghe@users.noreply.github.com> Co-authored-by: Henry Guo <marshawcoco@gmail.com> Co-authored-by: 唐小鸭 <tangtang1251@qq.com> Co-authored-by: houseme <housemecn@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com> Co-authored-by: cxymds <cxymds@gmail.com> Co-authored-by: cui fliter <imcusg@gmail.com> Co-authored-by: RJ Regenold <rregenold@teamraft.com> Co-authored-by: RJ Regenold <214054+rjregenold@users.noreply.github.com> Co-authored-by: GatewayJ <835269233@qq.com> Co-authored-by: Jason Kossis <jkossis@gmail.com> Co-authored-by: Hiroaki KAWAI <hiroaki.kawai@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2026-09-15 20:56:13 +08:00
cxymds	7abb0f5f1d	fix(heal): bind admin traversal to bucket incarnation (#7802) ... * fix(heal): bind admin traversal to bucket incarnation * fix(ecstore): reopen healthy hedged readers after peer loss * test(ecstore): isolate tier overwrite recovery scheduling * test(ecstore): observe tier cleanup under object read locks * fix(ecstore): bound decommission entry tracing * test(ecstore): drain incarnation heal fixture writes * test(heal): match debug server stack in deep heal fixtures * test(heal): include identities in C06 count failures * test(heal): drain PUT tails before inspecting B920 fixtures * test(scanner): isolate retained MRF retry slots * fix(ecstore): separate PUT cleanup intent from persisted metadata	2026-09-14 13:19:06 +08:00
cxymds	244e7dfb99	fix(heal): retire stale delete markers after bucket recreation (#7743) ... * fix(heal): prove completed historical version cleanup * test(heal): use debug runtime stack for C06 regression * fix(heal): retire stale delete markers after bucket recreation * test(ecstore): fix Clippy in retired marker regressions	2026-09-13 21:26:11 +08:00
cxymds	17ddecb075	fix(ecstore): gate shard integrity and preserve legacy recovery (#7741) ... * fix(ecstore)!: bind bitrot shards to immutable part identities Verify part, coding-index, and block identity across write, GET, and Heal paths. Preserve identities across metadata-only copies and repair, include them in multipart quorum selection, and require payload proof for receipts. Keep legacy decoding with conservative parity and target-digest validation, and document its unsupported cases and additional verification I/O. BREAKING CHANGE: New bound-v1 shards require compatible readers throughout the fleet. Legacy objects without sufficient integrity evidence return an error; binary rollback after new writes requires verified data migration. Refs: rustfs/backlog#2497 * fix(ecstore): preserve shard framing with independent integrity Commit immutable part-generation Merkle roots and replicated proof indexes without changing existing checksum frames. Verify reads, reconstruction and Deep Heal against metadata quorum; keep legacy reads and explicitly defer unproven legacy data repair. Preserve multipart rollback generations, require acknowledged durable index publication, and add decoder compatibility and donor-shard regression coverage. * fix(heal): verify protected partial-write replay	2026-09-13 21:25:58 +08:00
cxymds	f21b06dfd2	fix(heal): rebuild truncated xl.meta from healthy quorum (#7730) ... * fix(heal): rebuild truncated xl.meta from healthy quorum * fix(test): pass topology to heal overlap RPC regression * fix(test): drive heal admission alongside partial PUT Poll the partial PUT and its mock heal receiver together, bound their handshake, and retain the existing repair-scope assertions. * fix(test): prepare durable MRF fixtures and Linux heal stack * fix(test): drive tier cleanup recovery after deferred attempts --------- Co-authored-by: Hauser <housemecn@gmail.com>	2026-09-13 19:39:02 +08:00
cxymds	00aeb12914	fix(ilm): preserve cleanup ownership on tiered overwrites (#7639) ... * fix(ilm): preserve cleanup ownership on tiered overwrites * fix(ci): refresh E2E selection for tier overwrite regression	2026-09-10 20:14:07 +08:00
cxymds	88183daf10	feat(ilm): backfill proven legacy transition state (#7591) ... * feat(ilm): backfill proven legacy transition state * fix(ilm): remove redundant reconcile test clone Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: houseme <housemecn@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com>	2026-09-09 23:40:30 +08:00
houseme	4d1807c17f	refactor: share object version limit constants (#7420) ... * refactor: share object version limit constants Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> * fix(error): merge equivalent api message branches Combine the MaxVersionsExceeded and internal IO message branches so Clippy no longer flags identical if blocks while preserving the existing response messages. Co-Authored-By: heihutu <heihutu@gmail.com> Co-Authored-By: zhi22915 <qiuzgang@gmail.com> --------- Co-authored-by: zhi22915 <qiuzgang@gmail.com>	2026-09-07 22:29:37 +00:00
houseme	474fcf78fb	fix: align object version limit handling (#7415) ... Co-authored-by: zhi22915 <qiuzgang@gmail.com>	2026-09-07 23:43:19 +08:00
唐小鸭	899f81f3ad	fix(replication): resolve drifted replicas via a target version ledger (#7368) ... * fix(replication): resolve drifted replicas via a target version ledger A replication target that mints its own version ids (Wasabi, AWS S3) never answers to the source uuid, so every version-addressed mutation after the initial PUT failed forever: permanent version deletes answered NoSuchVersion every heal cycle, and tag / retention / legal-hold updates re-PUT the object, minting one more target version per update (rustfs/backlog#2340). Record the id the target assigned as a per-target ledger on the source version (replication-target-version-<arn>, written through the existing status writeback) and resolve every later mutation through it: version deletes DELETE the ledger id, metadata updates go through the metadata-only Object Lock and tagging APIs. Replicas written before the ledger existed are located by exact key and ETag, minus the candidates other generations of the key already claim through their own ledgers; an ambiguous remainder is refused with a backoff instead of guessed, since a wrong pick would destroy a live generation. A fresh write never consults content identity. NoSuchVersion on a version-addressed DELETE counts as purged. The fake target gains the Wasabi shape (404 NoSuchVersion on an unknown id, per-version Object Lock APIs) and the matrix covers the three mutation classes plus the same-bytes generation case. * fix(scanner): drop the unused Digest import Same one-line change as rustfs/rustfs#7366 (main is red with it under -D warnings); carried here so the stacked PRs' merge commits compile until that fix lands. * fix(admin): probe replication-check mutations by the assigned version id (#7373) On a target that mints its own version ids the DeleteMarker and VersionDelete phases of ?replication-check were skipped: they addressed the source id, which such a target never had. The replication worker now addresses the id the target assigned (the target-version ledger), and the probe already holds that id from its own PUT, so run both phases against it. VersionFidelity keeps failing with the mismatch code and the target stays FAILED; the phases report whether ledger-addressed purges work against this endpoint (rustfs/backlog#2340). * fix(replication): abandon purges to targets the bucket no longer names (#7377) * fix(admin): probe replication-check mutations by the assigned version id On a target that mints its own version ids the DeleteMarker and VersionDelete phases of ?replication-check were skipped: they addressed the source id, which such a target never had. The replication worker now addresses the id the target assigned (the target-version ledger), and the probe already holds that id from its own PUT, so run both phases against it. VersionFidelity keeps failing with the mismatch code and the target stays FAILED; the phases report whether ledger-addressed purges work against this endpoint (rustfs/backlog#2340). * fix(replication): abandon purges to targets the bucket no longer names A permanent version delete whose replication keeps failing stays in xl.meta as a PENDING purge, hidden from listings, until every target confirms it. Once the operator removes the replication configuration or the rule naming that target nothing ever confirms it: the heal path derived its delete decision from the configuration (the decision string is not persisted) and skipped the version forever, so DeleteBucket answered BucketNotEmpty for a residue the client could neither list nor remove (rustfs/backlog#2340). Owe a version purge to the targets its purge state names, let the heal path through without a configuration, and have the delete worker settle a target the configuration no longer names as abandoned: the purge is reported complete locally through the normal writeback, the replica on the former target is left alone, and the event replication_purge_abandoned plus a counter are the record. * fix(admin): send replication-check marker creation without a version id Running the DeleteMarker / VersionDelete phases on a target that mints its own version ids exposed two probe-shape bugs on real Wasabi: - the DeleteMarker phase put the assigned version id on its DELETE. A RustFS peer reads the source-deletemarker header and creates a marker, but a generic S3 target executes it as a permanent delete of the probe version, so VersionDelete then answered NoSuchVersion. Use the same wire shape as live delete replication: no versionId on a marker creation. - cleanup treated NoSuchVersion on the version the VersionDelete phase had already removed as a failure (RustFS/MinIO answer 204 there). Also gate the no-configuration heal pass-through for pending purges on a purge state that actually names targets, so a purge without a recorded target keeps the ordinary skip (scanner unit test), and merge origin/main (#7365 settles the pool-metadata probe test that failed in CI). --------- Co-authored-by: houseme <housemecn@gmail.com>	2026-09-07 11:23:32 +00:00
唐小鸭	14c99a994c	fix(filemeta): keep data dir of a version awaiting purge replication (#7307)	2026-09-07 05:30:44 +08:00
cxymds	4dbc58887a	fix(tier): probe legacy transition version state (#7138)	2026-09-05 06:00:14 +00:00
Zhengchao An	6f717b2752	fix(filemeta): accept MinIO RFC1123 restore expiry-date (#7115)	2026-09-04 09:02:03 +00:00
cxymds	0181a583a6	fix(ilm): recover orphaned restore generations (#7104)	2026-09-03 20:03:51 +08:00
cxymds	86ebcb325c	fix(replication): fence stale metadata status writeback (#7083) ... Co-authored-by: houseme <housemecn@gmail.com>	2026-09-03 08:05:58 +00:00
唐小鸭	43450df589	fix(ecstore): keep degraded objects listable when drives are offline (#7010)	2026-09-01 20:16:57 +08:00
houseme	152f110583	revert: rollback AHashMap changes and keep using std HashMap (#6741) ... * Revert "perf(ecstore): use AHashMap for FileInfo metadata fields (#6738)" This reverts commit 13a2ae212e. * fix(filemeta): restore standard HashMap metadata (#6742) Remove the direct ahash dependency added for FileInfo metadata and revert the affected filemeta/ecstore call sites back to std::collections::HashMap. Co-authored-by: heihutu <heihutu@gmail.com> --------- Co-authored-by: heihutu <heihutu@gmail.com>	2026-08-27 20:46:08 +08:00
houseme	13a2ae212e	perf(ecstore): use AHashMap for FileInfo metadata fields (#6738)	2026-08-27 18:34:10 +08:00
Zhengchao An	57eaa8228d	fix(ecstore): migrate tier free versions during decommission (#6393)	2026-08-24 09:21:53 +08:00
Zhengchao An	5cedf73d7c	fix(ecstore): terminate walk directory streams (#6462) ... * fix(ecstore): terminate walk directory streams * test(e2e): refresh node service selection * fix(filemeta): initialize empty metacache streams	2026-08-23 21:32:39 +08:00
cxymds	9cda615519	fix(scanner): discover sub-quorum heal candidates (#6384) ... * fix(scanner): preserve unversioned heal retries * fix(scanner): bound orphan heal discovery fallback * fix(filemeta): fence unsafe heal key components * fix(scanner): preserve exact overflow heal versions --------- Co-authored-by: houseme <housemecn@gmail.com>	2026-08-23 16:46:36 +08:00
唐小鸭	1cf0f7af15	feat(replication): split oversized hot-path functions, proxy unreplicated reads, and fail SSE-C passthrough closed (#6170) ... * refactor(replication): split four oversized hot-path functions into focused helpers Pure-move decomposition of the four oversized functions flagged by the replication compatibility review (P1-18), unblocking migration milestone M2 which requires resyncer moves to stay mechanical: - resync_bucket (522 lines -> 61-line step sequence): leader lock, target resolution, walk/collector/worker spawning, and dispatch loop extracted into focused helpers; pure decision helpers (DTO builders, HEAD-result classification) separated from IO orchestration. - replicate_all (411 lines -> 113-line main body): initial target-info seeding, read/stat option builders, skip-path notes, target HEAD action resolution, and the multipart/single-put payload transport extracted as private free functions. - start_mrf_processor (306 lines -> 46-line spawn body): recovery guard, ledger load, per-entry replay (delete/object/metadata), and retained entry resolution extracted; retry bookkeeping semantics preserved exactly (inner continue-paths push inside helpers, outer Missed push stays in the loop). - apply_iam_item (255 lines -> match dispatch skeleton): one helper per IAM item type. No behavior change: log texts, error paths, event emissions, and metric counts are byte-identical; existing tests unchanged and green (238 ecstore replication/mrf/resync + 232 rustfs site-replication). * feat(replication): proxy GET/HEAD/Tagging for unreplicated objects to replication targets (#6172) * feat(replication): proxy GET/HEAD/Tagging for unreplicated objects to replication targets Implements the MinIO active-active read-proxy protocol (P1-5 of the replication compatibility review): when a GET/HEAD/GetObjectTagging/ PutObjectTagging/DeleteObjectTagging request fails locally with not-found and the bucket has replication targets, the request is proxied to the targets in rule order, mirroring bucket-replication.go proxyGetToReplicationTarget/proxyHeadToRepTarget/proxyTaggingToRepTarget. Protocol surface: - Anti-loop: inbound {x-rustfs-,x-minio-}source-proxy-request is parsed into ObjectOptions (proxy_request + proxy_header_set, matching MinIO ProxyRequest/ProxyHeaderSet); a request carrying the marker with ANY value is never re-proxied. Outbound client proxy calls send the marker as "true"; replication worker convergence HEADs send it as "false" so a peer's proxy layer cannot answer a convergence check by proxying back to the source (which would fake Completed without a PUT). - Target selection: new replication_proxy.rs get_proxy_targets — empty when the marker is set, versioning is suspended, or no replication config; otherwise filter_target_arns -> TargetClient lookup, skipping targets with proxying disabled. - TargetClient gains head_object_for_proxy/get_object (streaming) and the three tagging calls. Proxy calls never send the replication-check SSE-C exemption header; customer SSE-C keys are forwarded verbatim so the target performs real decryption. Conditional (If-*) headers are not forwarded (MinIO parity); Range and part_number are, with parts_count/tag_count/storage_class/expiration passed through. - Metrics: proxy counters now count only real client proxy traffic, MinIO-aligned (one total per proxied request, one failed when no target served it). The previous misattributed counters — replication worker HEAD/PUT (#2672) and local tagging operations (#2682) — are removed; ReplProxyMetric now maps the tagging counters instead of dropping them. e2e (fake_s3_target extended with tagging + header journaling): proxied GET body + outbound header contract (marker present, no replication-check, SSE-C passthrough), HEAD, anti-loop 404 with zero outbound requests, GetObjectTagging, and metric mapping unit tests. Rolling note: proxying only activates for buckets with replication targets; requests carrying the marker keep pre-upgrade behavior. Refs rustfs/backlog#1675 (P1-5) * fix(replication): fail SSE-C passthrough closed on targets that drop transport headers (#6178) SSE-C ciphertext passthrough replicates via X-Rustfs-Replication-* transport headers. A MinIO/generic-S3 target silently discards them, storing bare ciphertext with no decryption material — yet the PUT succeeded, so the object reported COMPLETED with a silently unreadable replica (backlog#1675 N2). Fail-closed design: - SsecPassthroughCapability {Unknown, Supported, Unsupported} cached in BucketTargetSys per target ARN with a recording timestamp. Entries reset whenever the target is rebuilt, edited, or removed (arn_remotes_map lifecycle) and expire after SSEC_PASSTHROUGH_CAPABILITY_TTL (10 minutes): an expired verdict in either direction is re-earned through the audit, so an Unsupported target recovers automatically after an upgrade (at most one wasted PUT+HEAD audit per bad target per TTL window) and a Supported verdict cannot outlive a backend swapped behind the same endpoint. - Replication worker (replicate_object and replicate_all): fresh Unsupported targets never receive the PUT — the attempt fails immediately into the normal MRF retry channel with a "run ?replication-check to re-probe" hint. Unknown or expired verdicts are audited: after the PUT the worker HEADs the replica back through the replication-check channel (source version id mapped through resolve_read_api_version_id, so null-version objects audit correctly) and requires SSE-C evidence (the echoed customer-algorithm header); missing evidence records Unsupported and fails the attempt. Convergence HEADs are audited the same way, so a broken ciphertext replica from an earlier attempt can never launder itself into COMPLETED via an ETag match. The gate/evidence policy is pure (replication_target_boundary, staleness folded in as an input) for the M2 worker migration. - replication-check grows an SsecPassthrough probe phase: a probe PUT carrying the live transport-header shape, HEAD-back for evidence, and a machine-readable Code BucketRemoteSsecPassthroughUnsupported on failure. The probe verdict is synced into the runtime capability cache. Unlike VersionFidelity, a failed SsecPassthrough phase does NOT fail the target overall — it is a capability limit, not a broken replication contract, and a plaintext-only deployment against such a target must not turn red. - fake_s3_target: default mode now models a RustFS target (stores the transport headers, echoes SSE-C evidence); the new drop_unlisted_replication_headers mode models MinIO. The journal records whether a request carried transport headers. Receiver-echo verification: the replication-check HEAD exemption only skips SSE-C key validation; the response has always built sse-customer-algorithm from stored metadata (rustfs/src/app/object_usecase.rs), so no receiver change was needed — pinned end to end by the replication-check e2e against a real RustFS target. Rolling-upgrade constraint: RustFS targets older than the replication-check HEAD exemption (#5898) answer the audit HEAD without SSE-C evidence (or fail it outright), so SSE-C replication to such targets reports FAILED. This is deliberate — FAILED-and-retryable beats a silently undecryptable replica — and self-heals: once the target is upgraded, the next TTL expiry (or a manual ?replication-check re-probe) re-audits and records Supported. Plaintext and managed-SSE replication are unaffected. The capability cache is per-node; each node audits independently. Known limitations: - The audit judges evidence from the echoed customer-algorithm header only. A hypothetical target that preserves that one header while dropping other transport headers (partial-drop) would pass the audit; no known target behaves this way — observed targets drop the whole unknown-header family. - A mixed-version target cluster can flap the verdict between audits routed to different target nodes until the rollout completes; the TTL bounds how long each stale verdict persists. New e2e (backlog#1675 C1 + N2, red-first): fail-closed against a header-dropping fake (FAILED + no second PUT via the capability cache, journal-asserted; red run showed the old COMPLETED), replication-check reports the SsecPassthrough phase Code while the target stays OK overall, SSE-C heal convergence after a real target outage, and SSE-C existing-object resync landing a REPLICA readable with the customer key. TTL expiry in both directions is pinned at the cache and gate seams. * refactor(replication): move resyncer pure decision logic into rustfs-replication (M2) (#6180) * refactor(replication): move resyncer pure decision logic into rustfs-replication (M2) Pure-move milestone M2 of the ECStore replication split (backlog#1675 P1-17): relocate the resyncer's IO-free decision helpers, with their unit tests, into the crates they already belong to by type ownership. No behavior change. Moved into crates/replication: - resync.rs: resync_status_duration - delete.rs: resync_existing_delete_replication_info, replicate_delete_outcome, target_delete_version_id, delete_marker_purge_version_id, delete_marker_purge_mrf_entry - object.rs: version_identity_drifted, is_replication_target_offline_error, SsecPassthroughCapability, SsecPassthroughGate, ssec_passthrough_gate, ssec_passthrough_evidence_present (param-demoted to the echoed customer-algorithm string; ECStore keeps the HeadObjectOutput adapter) - filemeta.rs: NULL_VERSION_ID wire literal (crate-owned copy per the filemeta-independence contract) ECStore rewiring (Rule #14: imports stay in *_boundary.rs): - resync/object-decision/target boundaries re-export the moved symbols; resyncer call sites are unchanged - bucket_target_sys keeps only the verdict cache + TTL and re-exports the capability enum so existing consumer paths keep compiling Not moved (signatures carry ECStore or aws-sdk types): verify_resync_head_result, resync_target_error_detail, the SdkError classifiers, the replicate_all_* option/info builders, and the env-coupled bounded_resync_max_jobs admission clamp. README milestone table updated. * chore(replication): retire the datatypes.rs relay early README sanctions retiring datatypes.rs ahead of M4. The module was a pure relay (resync boundary -> datatypes -> mod.rs facade) with no external consumer importing it directly, so the facade now re-exports ResyncStatusType from replication_resync_boundary and the relay file is deleted. Consumers stay behind the ECStore facade, keeping Migration Rule #15 intact — the original retirement wording ("consumers import through rustfs-replication directly") conflicted with that rule and is corrected in the README. * chore(arch): extend migration guards to the M2-moved decision contracts The adversarial review of the M2 move found the per-symbol ratchet in check_architecture_migration_rules.sh was not extended for the moved symbols, leaving them free to be redefined in ECStore or imported past their boundary without CI noticing: - resync definition pin + boundary fences gain resync_status_duration; - the object-decision boundary fences gain the five delete-family helpers (delete_marker_purge_mrf_entry, delete_marker_purge_version_id, replicate_delete_outcome, resync_existing_delete_replication_info, target_delete_version_id); - the target-boundary fence gains the SSE-C gate family, the offline classifier, and version_identity_drifted; - a new definition pin rejects ECStore redefinitions of the M2-moved fns/enums (ssec_passthrough_evidence_present deliberately excluded: ECStore keeps a thin HeadObjectOutput adapter under that name). Mutation-verified: a probe fn ssec_passthrough_gate under crates/ecstore/src/bucket/replication trips the new pin. Also anchors the intentionally-duplicated NULL_VERSION_ID wire literal from the filemeta side and tightens the M2 README note on bounded_resync_max_jobs.	2026-08-18 21:45:38 +08:00
Henry Guo	1619c4be60	fix(scanner): add context to corrupt metadata logs (#6099) ... Co-authored-by: Henry Guo <marshawcoco@users.noreply.github.com>	2026-08-15 21:32:05 +08:00
houseme	5b54c4303d	fix(ecstore): reconcile object cleanup receipts (#6077) ... * fix(s3): keep multipart completion publication owned Co-Authored-By: heihutu <heihutu@gmail.com> * fix(s3): keep put publication owned Co-Authored-By: heihutu <heihutu@gmail.com> * chore(app): route multipart context through facade Co-Authored-By: heihutu <heihutu@gmail.com> * fix(ecstore): gate object transaction fencing Co-Authored-By: heihutu <heihutu@gmail.com> * fix(ecstore): fence object transaction epochs Co-Authored-By: heihutu <heihutu@gmail.com> * fix(ecstore): reconcile old data cleanup receipts Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: heihutu <heihutu@gmail.com>	2026-08-13 18:08:50 +00:00
cxymds	e11fcfbd08	fix(rebalance): converge multipart data movement retries (#6057) ... * fix(rebalance): converge multipart data movement retries * fix(rebalance): harden multipart retry replacement * fix(rebalance): isolate internal multipart uploads * test(ecstore): adapt metadata mutation fixtures * fix(rebalance): preserve transition metadata semantics * refactor(ecstore): reuse internal metadata matcher * Revert "refactor(ecstore): reuse internal metadata matcher" This reverts commit c87ca0328f. * refactor(rebalance): reuse data movement log constants * fix(rebalance): isolate migration-owned state * fix(rebalance): preserve pre-gate retry compatibility	2026-08-13 06:12:26 +00:00
Zhengchao An	60d8e8a20b	refactor(kms): consolidate encryption metadata key constants into their shared home (#5995) ... The shared module rustfs_utils::http::object_encryption_keys is the single source of truth for encryption metadata key names, but three call sites still carried their own copies or bare literals: crates/kms/src/service.rs (two private constants plus four bare x-rustfs-encryption-* literals on both the write and read path), rustfs/src/app/select_object.rs (six SELECT_* copies), and rustfs/src/storage/options.rs (two private prefix copies now imported from header_compat). All values are unchanged, so the change is a compiler-verified rename. The reader-only x-rustfs-internal-server-side-encryption- family gets a named constant with the verified judgment recorded on it: no writer emits these keys anywhere in the repo (the SSE writer persists the MinIO-branded keys verbatim for interop), the two comments claiming the dual-key invariant writes this twin were wrong and are corrected, and the defensive redaction/strip readers are kept because removing them is risk-asymmetric. rustfs-kms's rustfs-utils dependency now declares the http feature it uses instead of relying on feature unification from sibling crates. Refs rustfs/backlog#1775, rustfs/backlog#1562.	2026-08-12 16:37:38 +00:00
Zhengchao An	be0cea83b7	test(ecstore): pin persisted metadata key literals and bucket config goldens (#5904)	2026-08-09 22:12:26 +00:00
唐小鸭	10c7476883	fix(replication): rebuild SSE metadata boundary for encrypted objects (#5872) ... Groundwork for encrypted-object replication (backlog#1783, PR-A of 3): - classify_replication_source_encryption: accept the AES256 marker that every stored SSE-C object carries; the SseC arm was unreachable. - Fail closed on sealed material without an SSE marker (MinIO-written objects) instead of replicating ciphertext as plaintext. - Replace the dead VALID_SSE_REPLICATION_HEADERS table with a transport map keyed by the metadata keys the SSE writer actually persists, shared via the new rustfs_utils::http::object_encryption_keys module. - Structurally strip all encryption metadata from outbound replication (x-rustfs-encryption-* envelopes previously passed the filters). - Skip decrypt_checksums for encrypted objects at the boundary so its is_multipart=false (a response-path contract) cannot misroute encrypted multipart objects once managed replication opens. - Redact X-Rustfs-Replication-* SSE transport values in FileInfo Debug. A reconciliation test pins that every key encryption_material_to_metadata produces is either transport-mapped or stripped. All four SSE replication e2e contracts still assert FAILED unchanged.	2026-08-09 03:05:11 +00:00
houseme	c2e23411e8	test(filemeta): cover crc heal classification (#5841) ... * fix(filemeta): classify xl.meta CRC mismatch as FileCorrupt so heal repairs it A failed CRC means the metadata bytes on disk are not the bytes that were written — bitrot. Raising it as Error::other() surfaces a generic Io error, which should_heal_object_on_disk does not recognise as heal-worthy: the drive is skipped, disks_to_heal_count stays 0, heal_object returns ok, and the corrupted xl.meta is never rewritten — while the scanner re-submits the same no-op heal every deep-scan cycle. An explicit admin deep heal fails the same way, so no heal path repairs metadata bitrot, and every one of them reports success. check_xl2_v1 already classifies a short or wrong-magic header as FileCorrupt for exactly this reason (#5716); this completes the pattern for the two CRC sites. The existing From<rustfs_filemeta::Error> for DiskError conversion maps the variant to DiskError::FileCorrupt, which the heal path already handles. The previously silent is_indexed_meta site now logs the mismatch (structured event shape) like unmarshal_msg does. Regression test: corrupt one byte of a marshalled FileMeta and assert unmarshal_msg reports FileCorrupt; fails on the previous code, which returned Io(Other). Verified end-to-end on a 3-node / 12-drive EC:4 cluster: xl.meta corrupted on 2 of 12 drives via dd, admin deep heal — before this change the heal returns ok with the corruption intact and the scanner loops forever; with it, both copies are rewritten (decode-identical to the healthy quorum), the object reads back byte-correct, and a follow-up heal reports all twelve drives clean. * test(filemeta): cover crc heal classification Add regression coverage for the indexed xl.meta CRC path and the metadata-heal decision that consumes FileCorrupt. Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: terem42 <9478806+terem42@users.noreply.github.com> Co-authored-by: heihutu <heihutu@gmail.com> Co-authored-by: zhi22915 <qiuzgang@gmail.com>	2026-08-08 11:36:44 +00:00
terem42	7e8b500420	fix(filemeta): classify xl.meta CRC mismatch as FileCorrupt so heal repairs it (#5838) ... A failed CRC means the metadata bytes on disk are not the bytes that were written — bitrot. Raising it as Error::other() surfaces a generic Io error, which should_heal_object_on_disk does not recognise as heal-worthy: the drive is skipped, disks_to_heal_count stays 0, heal_object returns ok, and the corrupted xl.meta is never rewritten — while the scanner re-submits the same no-op heal every deep-scan cycle. An explicit admin deep heal fails the same way, so no heal path repairs metadata bitrot, and every one of them reports success. check_xl2_v1 already classifies a short or wrong-magic header as FileCorrupt for exactly this reason (#5716); this completes the pattern for the two CRC sites. The existing From<rustfs_filemeta::Error> for DiskError conversion maps the variant to DiskError::FileCorrupt, which the heal path already handles. The previously silent is_indexed_meta site now logs the mismatch (structured event shape) like unmarshal_msg does. Regression test: corrupt one byte of a marshalled FileMeta and assert unmarshal_msg reports FileCorrupt; fails on the previous code, which returned Io(Other). Verified end-to-end on a 3-node / 12-drive EC:4 cluster: xl.meta corrupted on 2 of 12 drives via dd, admin deep heal — before this change the heal returns ok with the corruption intact and the scanner loops forever; with it, both copies are rewritten (decode-identical to the healthy quorum), the object reads back byte-correct, and a follow-up heal reports all twelve drives clean.	2026-08-08 18:48:18 +08:00
houseme	e342457830	perf(filemeta): reduce meta object key allocations (#5836) ... Co-authored-by: heihutu <heihutu@gmail.com>	2026-08-08 17:23:08 +08:00
terem42	cb93ac5df1	fix(ecstore): purge the stale destination data dir on healing rename_data commits (#5822) ... * fix(ecstore): purge the stale destination data dir on healing rename_data commits Heal commits reuse the version's existing data_dir, so when repairing in-place corruption (bitrot) the destination directory still exists and holds the corrupt shard files. rename(2) cannot replace a non-empty directory (EEXIST on XFS, ENOTEMPTY on ext4), so the commit failed on every attempt — including all scheduler retries — and in-place bitrot was detected and reconstructed but never repaired. Purge the stale destination data dir (move_to_trash) before the commit rename, for healing commits only: fresh PUTs mint a new data_dir and can never collide, and a non-healing collision keeps failing loudly. Adds the FileInfo::is_healing() reader for the marker set_healing() already writes. * style(ecstore): emit the heal purge failure as a structured event The new warning was the only sentence-style log in `rename_data`'s commit path — it sat ten lines above `info!(event = EVENT_DISK_LOCAL_RENAME_REJECTED, component = ..., subsystem = ...)` and interpolated its values into the message instead of carrying them as fields, so it is invisible to any operator query keyed on `event`. Give it the shape the rest of the file uses: a named `EVENT_DISK_LOCAL_HEAL_PURGE_FAILED`, `component`/`subsystem`, `dst_path` and `error` as fields, and a short label as the message. Level stays `warn` — the purge is best effort and the rename below fails closed — and the condition, the branch, and the control flow are unchanged. --------- Co-authored-by: Zhengchao An <anzhengchao@gmail.com>	2026-08-07 23:10:53 +00:00
唐小鸭	3792fed827	fix(replication): madmin reset/diff wire compat and config validation (#5799) ... * fix(admin): align replication-reset responses with madmin ResyncTargetsInfo shape The replication-reset and replication-reset-status responses serialized their shell as "Targets" and per-target fields in PascalCase, while madmin-go ResyncTargetsInfo/ResyncTarget expect the "target" shell key and lowercase field tags (arn/resetid/resyncStatus/replicationCount/ completedReplicationSize/failedReplicationCount/failedReplicationSize). Go json decoding is case-insensitive per field, but Targets vs target, Status vs resyncStatus and the size/count key names cannot match, so mc replicate resync decoded empty results. Rename the serde tags to the exact madmin wire shape, keep the ResetBeforeDate/Error RustFS extension keys (unknown keys are ignored by Go decoders), pin the shape with a snapshot unit test, and update the e2e client DTO to decode the madmin shape. * fix(admin): stream bare madmin DiffInfo documents from replication diff POST /v3/replication/diff returned a single enveloped object ({Entries, IsTruncated, ScannedVersions}) while madmin-go BucketReplicationDiff decodes the body with a json.Decoder loop over bare DiffInfo documents. The envelope decoded as exactly one DiffInfo with an empty object, so mc replicate diff printed a phantom empty row instead of the real backlog. Emit one DiffInfo JSON document per line by default, using the exact madmin json tags (object/versionId/rStatus/deletemarker/lastModified; Size stays as a RustFS extension key that Go decoders ignore). The enveloped shape moves to the opt-in ?aggregate=true RustFS extension, which remains the only carrier of scan-coverage metadata; a truncated default-mode scan is surfaced via a warn tracing event instead of in-stream. Pin both shapes with unit tests and tighten the e2e helper to reject any envelope in the stream. * feat(replication): validate replication config structure before persisting PutBucketReplication accepted structurally invalid configurations that MinIO's replication.Config.Validate rejects: empty or oversized rule lists, duplicate or negative rule priorities, over-long rule IDs, filters carrying more than one of Prefix/Tag/And, and delete marker replication enabled on tag-filtered rules. Such configs persisted silently and later produced undefined routing (e.g. ambiguous priority ties) instead of failing the PUT. Add validate_replication_config_structure as a pure function in rustfs-replication (limits documented as constants), surface it through the ecstore api facade, and run it first in the PUT capability gate so defects are named before any metadata write. Missing Priority counts as zero for the uniqueness check, matching Go's zero-value semantics. The self-target rejection deliberately stays at set-remote-target, where the endpoint is known; a config can never reference a self-pointing ARN. Document the rule-level Destination.StorageClass contract (use the remote target's storage_class instead) and renumber the acceptance matrix e2e to unique priorities, which MinIO would also require. * test(replication): pin duplicated wire types with boundary reconciliation tests rustfs-filemeta (xl.meta disk format) and rustfs-replication (MRF/resync persistence format) deliberately each own ReplicationStatusType, VersionPurgeStatusType and ReplicationState; the boundary converts between them via as_str(), whose From<&str> impls fall back to Empty on unknown tokens — a variant added on one side silently degrades to Empty on the other. Add reconciliation tests in replication_filemeta_boundary: exhaustive matches with no wildcard arm on both sides of both enums (a new variant fails compilation until the mapping is reconsidered), string-token round-trip asserts (a token the other side does not recognize fails instead of quietly becoming Empty), and a full-field ReplicationState round-trip. Cross-reference the tests from both type definitions. Struct drift was already compile-guarded by the exhaustive struct literals in the conversion functions. * docs(replication): define split completion criteria and milestone sequence The ecstore replication split plan had no completion measure — the boundary scaffolding risked ossifying because nothing said when the migration counts as done. Record the criteria in the module inventory: done means the Required Contracts table's 'Current dependency to remove' column is empty; the end state moves pool/resyncer/state into crates/replication, with the boundary micro-files dissolving as code crosses the crate line (batch-merging them beforehand is explicitly rejected — the guard scripts anchor on their file names, so merging is churn with zero functional gain; only datatypes.rs can retire early). Sequence the remaining work as M2 (resyncer pure decision logic, after the oversized function splits) → M3 (worker runtime, highest risk, last) → M4 (retire boundaries and guard entries). Refresh the stale first-step text — the event sink / runtime contracts already landed — and update the split-plan status table accordingly. * fix(replication): align structural validator with MinIO semantics after adversarial review Three interop corrections found by adversarial review of the new structural validator, plus review fallout fixes: - Delete-marker replication is now rejected only for a direct Filter.Tag, not for tags inside Filter.And — MinIO's validator only inspects the direct tag, and mc replicate add --tags "k1=v1&k2=v2" (delete-marker replication on by default) puts multiple tags into And.Tags, so the stricter check rejected mc-generated configs MinIO accepts. - Rule ID length is measured in bytes (Go len semantics), not chars — a 255-char multibyte ID must not round-trip into a config MinIO rejects. - An empty <Tag/> element (no key) counts as absent, matching MinIO's Tag.IsEmpty(); console form serializers emit empty tags, which would otherwise trip the exactly-one-of and delete-marker checks. Also: repair the store-uninitialized PUT test whose empty-rules fixture now (correctly) fails structural validation before reaching the store lookup; pin the previously untested startTime madmin key in the reset-status shape test; and signal a truncated default-mode diff scan via the x-rustfs-replication-diff-truncated response header — the bare madmin stream has no envelope, so a truncated scan was otherwise indistinguishable from a complete healthy one (madmin/mc ignore unknown headers). * test(e2e): activate SSE-S3 replication contract and pin resync fail-closed path The SSE-S3 replication contract e2e was ignored under backlog#1291 (silent plaintext replication); the fail-closed gate in replication_target_boundary.rs closed that hole, so the ignore reason expired. Un-ignore the test — it now pins the current fail-closed contract (FAILED status, failure event, readable encrypted source, stable absence of all target versions), verified green. Add test_bucket_replication_sse_s3_resync_stays_fail_closed: drives the existing-object resync path (PUT ?replication-reset) over a FAILED SSE-S3 object and asserts the resync generation reaches a terminal state without ever materializing a target version, with the stays-absent window also spanning fast-scanner heal cycles. The new start_bucket_replication_reset helper doubles as the madmin ResyncTargetsInfo shape assertion (target[0].arn/resetid) for the reset-start response. Refresh the stale nextest count commentary (the module is at 20 fast + 36 nightly = 56 tests by cargo nextest list; the SSE-S3-ignored note no longer holds).	2026-08-07 22:30:12 +08:00
Zhengchao An	f73054f6ad	fix(s3): degrade multipart listings per upload instead of failing the bucket (#5721) ... The multipart staging namespace is one flat set of sha256(bucket/object) directories shared by every bucket, and the cross-set listing rewrite reads every upload's metadata. Two shapes poisoned the whole ListMultipartUploads response with InternalError: Corrupted format: a healthy in-flight upload belonging to another bucket (its stored owner bucket fails the guard and fell into the corrupted-format arm), and a single upload directory whose xl.meta was torn by an unclean shutdown. Docker Distribution calls ListMultipartUploads on every PATCH/commit, so either shape broke OCI registry pushes entirely (issue #5716). Foreign-bucket uploads are now skipped silently, and directories whose metadata is affirmatively corrupt at quorum are skipped with a debug log, while every other decode failure (quorum loss from offline disks, timeouts, transport errors) keeps failing the listing so clients retry instead of silently losing entries. The degrade-vs-propagate decision is a named corrupt-family classifier with a unit test pinning both sides. FileMeta::check_xl2_v1 now classifies a missing or wrong XL2 magic as FileCorrupt instead of an anonymous io error so damage is distinguishable from transient IO faults. Refs #5716	2026-08-05 03:49:52 +00:00
Zhengchao An	5bd28048d5	fix(filemeta): redact sealed keys and elide inline data in FileInfo Debug (#5725) ... FileInfo's derived Debug printed the full metadata map (including X-Rustfs/X-Minio-Internal-Server-Side-Encryption-Sealed-Key and -Iv values, i.e. KEK-wrapped DEK ciphertext) and the full inline data bytes (plaintext user content for non-SSE small objects), so any whole-struct log dump such as the heal_object dumps leaked user data and sealed key material into logs. Replace the derive with a manual Debug impl that redacts encryption metadata values (keys stay visible, values print as redacted with length) under both internal prefixes, and elides data/checksum bytes to a length summary. The exhaustive destructuring forces every future field through an explicit show/redact decision. starts_with_ignore_ascii_case is made pub in rustfs-utils for reuse.	2026-08-05 02:07:01 +00:00
Zhengchao An	cfce7bd9b1	fix(filemeta): preserve FileInfo wire compatibility (#5689)	2026-08-04 09:25:28 +00:00
Zhengchao An	5237a4465d	feat(replication): purge delete markers by the target's own version id (#5676) ... * feat(replication): purge delete markers by the target's own version id When a delete marker is replicated, the target assigns it a version id. The purge that follows derived one from the *source* uuid instead, which is only correct when the target mirrors source version ids. A generic S3 target does not: the derived id addresses a version that does not exist there, so the purge is a no-op and the replica keeps a marker the source has already removed. Same failure class as #4401. Record the id the target reports and address it directly on purge. Data path, all of it driven by the object's internal metadata rather than the `ReplicationState` wire form, which encodes positionally and cannot carry a map: - `rustfs-utils`: the `replication-delete-marker-version-<arn>` key family, plus `strip_internal_prefix_preserving_case` — ARNs are case-sensitive and the existing `strip_internal_prefix` lowercases. - `ReplicationState` gains the map and a `..._corrupt` flag, both `#[serde(skip)]`; `ReplicatedTargetInfo` carries the per-target id. - `persist_target_delete_marker_versions` is merge-only. A delete arriving over internode RPC has an empty map, so treating it as authoritative would let a remote disk erase an id the local disk still holds. - `delete_object_version` copies the map into `fi.metadata` before dispatch, so the durable carrier crosses the wire even though the field does not. - The keys are folded into the quorum hash through their normalized form: the dual internal prefixes carrying one mapping share an identity, while a genuine disagreement between disks still shows up as a quorum difference. - `corrupt` (the prefixes disagreed) fails closed: skip the purge and warn rather than guess an id and risk destroying a live version on the target. Ported from the rc.1 branch, which cannot merge as a whole: its MRF replay rewrite collides with #5659/#5671/#5672/#5673 and regressed `MRF_PENDING_CAP`. main's MRF machinery is kept; only this capability moves across. It touches no MRF code. Two things did not survive the port, deliberately. The branch's `missing_is_complete` purge regression does not exist here — it came from its own HEAD-precheck rewrite, and main's simpler path never had it. And the branch's `MrfReplicateEntry` ordering fields are MRF-redesign scope, left behind. Verification: cargo fmt --all --check, git diff --check, cargo check --workspace --all-targets, and the suites for the four touched crates — 4070 tests, 2 pre-existing failures unrelated to this change (`system_resolver_negative_result_reaches_the_dns_allowlist`, `test_resolve_domain_preserves_system_resolver_error_provenance`; both are the sandbox DNS interception, they fail on a clean checkout too). * fix(replication): keep the layer guard happy scripts/check_architecture_migration_rules.sh matches on text, so the doc comments naming `rustfs_filemeta::` read as a cross-layer dependency even though nothing imports it. Reword them; the guard passes. * fix(replication): make the target-version cap deterministic Two defects in this PR, both found in review. The cap was applied while iterating a `HashMap`, so *which* 1000 entries survived depended on iteration order. Two disks decoding the same oversized metadata could keep different subsets, hash differently, and lose quorum — instead of both reporting the same corruption. Collect first, then truncate in `BTreeMap` order, which is total and identical everywhere. And `persist_target_delete_marker_versions` discarded the `corrupt` flag from the RPC carrier, committing a delete-marker update that looked clean while the exact remote marker identity was unknown. It now declines to merge a corrupt carrier. Because the helper only ever inserts, declining leaves the durable keys already on the object untouched, which is strictly safer than writing a mapping we cannot trust. Residual, stated rather than papered over: corruption confined to the RPC carrier is not persisted as a sentinel, so a later reader of an object that carried no durable keys still sees "legacy, no mapping" rather than "corrupt". Persisting that would need a wire-format addition; the consumer already fails closed on any corruption it can observe. New test: `target_delete_marker_versions_cap_is_deterministic_across_decodes` decodes the same 1050-entry map twice and asserts both the corrupt flag and the retained subset agree. * fix(replication): preserve multipart source mtime (#5669) * fix(kms): repair unopenable ciphertext and cover the Vault backends (#5668) * Add black-box behavior tests for KMS resilience and serialization * fix(kms): repair unopenable ciphertext across backends Black-box testing of the KMS crate surfaced several defects that make encrypted data permanently unreadable. Symmetric envelopes. The Local and Vault Transit backends returned raw cipher output from `encrypt` while `decrypt` parsed a JSON envelope, so anything sealed through the master-key path could never be opened again. Local also discarded the AES-GCM nonce. Both now emit the same envelope `decrypt` consumes, matching the Static backend. Deterministic AAD. The object layer derived AEAD additional data by serializing a `HashMap` directly. Iteration order differs per instance, so a context rebuilt from storage produced different AAD bytes than the one used to seal and the object stopped opening. Ordering by key removes that dependency, matching the Static backend's existing `context_aad`. Objects written with the default single-key context are unaffected, since a one-entry map has only one serialization. Cipher in the header projection. `metadata_to_headers` recorded the SSE mode (`AES256` / `aws:kms`), which cannot represent ChaCha20-Poly1305, so a ChaCha-sealed object came back claiming `aws:kms` and was opened with the wrong cipher. The cipher now travels in `x-rustfs-encryption-algorithm` — the header the storage layer already reads but nothing ever wrote. Objects without it fall back as before. Also: the Static backend ignored `key_spec` and always issued 256-bit data keys; Local `list_keys` hardcoded `truncated: false`, ignored `marker`, and paginated over unordered `read_dir`, so a paginating client silently saw a partial key list; and Local and Vault KV2 reported `key_id: "unknown"` from `decrypt` despite the envelope naming the master key. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(kms): cover both Vault backends and key rotation The behavior suite ran only against Local and Static, and its own harness documented the gap: the Vault backends had no business-capability coverage at all. Setting `RUSTFS_KMS_VAULT_TOKEN` now adds Vault KV2 and Vault Transit to every `for_each_backend` spec against a live server. That lane is what surfaced the Transit envelope defect fixed in the previous commit. `rotate` and `versioning` are advertised only by the Vault backends, so until now every capability-gated branch for them took the `UnsupportedCapability` side and the working half was never asserted — a rotation that dropped prior key versions would have gone green. The new `behavior_rotation.rs` pins that half: material sealed before a rotation still opens after it, repeated rotations accumulate versions rather than overwriting a single spare, and the history survives a restart. Two test defects fixed. `objects_round_trip_across_sizes_and_algorithms` asserted a 1-byte object differs from its own ciphertext, which collides once every 256 runs; the assertion now applies only where a collision is not realistic, and small objects stay covered by the tag check and the decrypt round-trip. `test_from_env_selects_token_file` depended on `RUSTFS_KMS_VAULT_TOKEN` being absent from the caller's environment and now clears it explicitly. The snapshots directory was also removed from `.gitignore`: insta snapshots are the assertions themselves, so leaving them untracked gives CI nothing to compare against. Only `.snap.new` scratch files are ignored now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(kms): adapt behavior suite to current key APIs Rebasing onto main brought four API changes the suite predates. `DeleteKeyRequest` gained `confirm_key_id`, and immediate deletion is now gated on the server's `allow_immediate_deletion`. Scheduled deletions pass `None`; the four specs that destroy a key outright echo the key id back and opt the harness config in, which is what the gate asks of a real caller. `LocalBackupExportRequest` gained `sanitized_config`. These specs cover the key-material path, so they seal no configuration and pass `None`. `KmsCacheStats` became a named struct with real hit, miss, and eviction counters. `cache_stats_returns_an_entry_count_and_no_hit_or_miss_data` existed to pin the old placeholder behavior — that the second tuple element was always zero — which main has since fixed, so it is now `cache_stats_reports_hits_and_misses_separately` and asserts the counters actually move. Starting the service provisions the reserved probe key, so it shows up in listings and backup bundles. Exact-set assertions filter it through a new `without_probe_key` helper rather than naming it, keeping those specs about the keys they seeded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(kms): bind the AAD to the stored context bytes Review caught that canonicalizing the AAD on decrypt breaks objects sealed before canonicalization existed, and it was right. The AAD is the *serialization* of the encryption context, and `x-rustfs-encryption-context` stores that exact byte sequence: `encrypt_object` fed one `HashMap` to the AEAD and then moved the same map into the metadata the header is written from, so the stored string is byte-identical to the AAD the object was sealed under. Those objects are therefore recoverable — but only while nothing round-trips the value through a `HashMap` and re-serializes it. Recomputing sorted AAD on decrypt would have turned a readable object into a permanently unreadable one. The previous behavior was worse than the first analysis credited: it did not merely fail intermittently, it made the failure deterministic. `EncryptionMetadata` now carries `context_aad`, the bytes the object was actually sealed with. Encryption records what it fed the AEAD, the header projection stores those bytes verbatim (and preserves a legacy ordering across a re-projection rather than rewriting it into sorted form), and `headers_to_metadata` carries the stored string through untouched. Both decrypt paths, SSE-KMS and SSE-C, prefer it and fall back to canonical serialization only when no stored serialization exists. Canonicalization still applies to everything newly sealed, so the original ordering bug cannot recur. Two tests pin this: a legacy record whose sealed bytes are non-canonical must survive a full header round trip unchanged, and a context header rewritten to an equivalent-but-reordered serialization must fail authentication rather than silently re-deriving a working AAD. Both were mutation-checked against the reinstated bug on each side. Also from review: the lifecycle churn test asserted only that every request was accounted for, which holds whether the state gate exists or not, so both branches are now pinned deterministically after the churn (asserting `refused > 0` on the concurrent phase would only trade the hole for a scheduling flake). And the Local and Vault KV2 envelopes compare `encryption_context` without authenticating it — `DekCrypto` seals only the plaintext — which is now documented at both sites; closing it needs a versioned envelope, since existing ciphertext was sealed without AAD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: ccccpj <ccccpj@outlook.com> Co-authored-by: 唐小鸭 <tangtang1251@qq.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 17:11:27 +00:00
houseme	7051a5ce41	feat: add opt-in hotpath profiling (#5488) ... * feat: add opt-in hotpath profiling Co-Authored-By: heihutu <heihutu@gmail.com> * test: fix vault kms client construction Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-31 01:49:19 +08:00
Zhengchao An	d39ffdb1cd	fix(filemeta): canonicalize version order after insert (#5413)	2026-07-29 05:49:00 +00:00
cxymds	294c79c156	fix(tiering): gate remote version state safely (#5374) ... * feat(tiering): model provider version capabilities * feat(tiering): persist opaque remote versions * fix(tiering): gate remote version state safely * fix(tiering): preserve remote version state on delete * fix(tiering): accept unversioned transition responses * fix(tiering): replay exact cleanup journals * test(tiering): pin empty exact cleanup guard * test(tiering): accept strict missing journal errors * test(tiering): exercise free-version identity guard * test(tiering): reach destination identity guard * test(tiering): persist version identity drift * test(tiering): bind version drift fixture --------- Co-authored-by: houseme <housemecn@gmail.com>	2026-07-29 02:43:28 +00:00
cxymds	5426237a49	fix(filemeta): preserve canonical version order (#5353)	2026-07-28 17:38:59 +08:00
cxymds	547c678eed	fix(filemeta): reject positive size without parts (#5354) ... * fix(filemeta): reject positive size without parts * test(ecstore): keep optimized read fixture valid * test(ecstore): keep listing fixtures valid	2026-07-28 17:35:53 +08:00
Henry Guo	376b90f61f	fix(lifecycle): back off idle free-version recovery (#5025) ... Co-authored-by: Henry Guo <marshawcoco@users.noreply.github.com> Co-authored-by: overtrue <anzhengchao@gmail.com>	2026-07-20 21:02:29 +08:00
houseme	9e4c5e949f	fix(ecstore): fence restore cleanup by operation id (#5058) ... Refs rustfs/backlog#1356 Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-20 10:32:02 +00:00
cxymds	b0c6c4cbce	fix(storage): resolve erasure parity per pool (#4977) ... * fix(filemeta): add state-aware file info validation * fix(filemeta): validate shard arithmetic and delete paths * fix(ecstore): add fallible erasure construction * fix(ecstore): resolve storage parity per pool * fix(storage): report heterogeneous erasure layouts * fix(admin): publish prepared storage config atomically * fix(storage): harden per-pool parity boundaries * fix(storage): address pre-PR validation findings * test(ci): fix strict-topology validation fixtures * fix(heal): preserve delete markers during repair * refactor(filemeta): drop unused ValidatedFileInfo witness ValidatedFileInfo wrapped an unread `_file_info` reference alongside an `Option<ValidatedErasureLayout>`, but only the layout was ever consumed. Return the layout directly from `FileInfo::validate` so the sole production consumer (`LocalDisk::check_parts`) and the two unit tests read it without the extra witness type and lifetime. No behavior change. * fix(filemeta): keep compressed and MinIO-migrated tiered objects readable The new decode-path validation rejected several legitimate on-disk shapes that older RustFS and MinIO-migrated data carry, turning readable objects into FileCorrupt: - Compressed objects written with an unknown upload size persist a negative per-part actual_size (the documented "unknown size" sentinel that ObjectInfo::get_actual_size already tolerates). validate_collection_contents rejected it via usize::try_from; now a negative actual_size skips shard validation and only real, non-negative sizes are checked. - MinIO-migrated objects transitioned to a versioned remote tier store the tier version id as a UUID string, not 16 raw bytes. MetaObject::into_fileinfo returned FileCorrupt (main tolerated it as None), making all versions of the object unreadable; MetaDeleteMarker free-version records took a Some(nil) sentinel path with the same effect, which also breaks free-version expiry (remote-tier leak). Both now decode through a shared transitioned_version_id_from_meta_sys helper: 16 raw bytes or a UUID string are accepted, anything else is tolerated as None instead of failing the read. Regression tests updated to assert the readable/compat behavior, with new tests covering MinIO string-form recovery. * fix(scanner): build the delete-marker test fixture without erasure geometry get_size_counts_delete_markers_separately_from_versions built its delete marker with `FileInfo::new(object, 1, 1)`, which attaches erasure geometry (data=1/parity=1/distribution). This PR classifies versions by shape via `is_storage_delete_marker()` (no geometry) rather than the raw `deleted` flag, so a geometry-bearing "delete marker" is correctly serialized as a purge-pending payload Object and counted as a version — CI saw summary.versions=3, expected 2. Real delete markers carry no erasure geometry (delete paths build them as `FileInfo { deleted: true, ..Default::default() }`), so construct the fixture the same way. It then classifies as a storage delete marker and the counts (versions=2, delete_markers=1) hold. This keeps the PR's more-correct classification, which prevents a purge-pending object's geometry from being dropped when serialized as a bare delete marker. * docs(changelog): note per-pool parity fix and storage-class startup upgrade caveat Records the #4801 per-pool erasure parity fix under Fixed, and documents the upgrade behavior where a persisted storage class that a small or heterogeneous pool cannot satisfy now fails startup — with the RUSTFS_STORAGE_CLASS_STANDARD recovery steps. Docs-only; covers R4 from the on-disk compatibility audit. * fix(heal): report parity from erasure geometry, not is_valid() heal_object set HealResultItem.parity_blocks via `if lfi.is_valid()`, which was missed by the migration of the other quorum/metadata predicates. With the new `is_valid()` semantics (full payload validation; delete markers now return false), a delete marker or a geometry-bearing version with a benign collection quirk would misreport parity as the pool default instead of its own. Use `has_valid_erasure_geometry()` — the narrow "does this carry erasure geometry" predicate the rest of the migration uses — so reporting matches the object's actual layout. Reporting-only; no data-path change. * fix(filemeta): do not silently serialize a non-canonical deleted FileInfo as an Object `From<FileInfo> for FileMetaVersion` classifies by `is_storage_delete_marker()` (shape), which correctly routes canonical delete markers to Delete and purge-pending payloads (deleted=true with real erasure geometry) to Object. But a `deleted` FileInfo that is neither a canonical marker nor a valid erasure payload would silently serialize as a zero-geometry MetaObject that later fails `validate_for_metadata_read`. Write paths validate first (`validate_for_erasure_write` / `validate_for_metadata_read`), so this is a caller bug; `From` is infallible, so surface it with a structured `warn!` on the malformed branch instead of writing corrupt metadata silently. Legitimate purge-pending objects (valid geometry) are unaffected — the guard only fires for `deleted && !has_valid_erasure_geometry()`. * test(filemeta): assert real historical xl.meta versions pass metadata-read validation Empirical companion to the code-reasoned decode-tolerance invariants (docs/architecture/erasure-coding.md §11) and the rolling-upgrade / MinIO-migration compatibility concern: the tightened `validate_for_metadata_read` runs on every local disk read and peer-RPC-decoded FileInfo, so it must accept every version of real historically-written xl.meta, never reject it as FileCorrupt. Loads five real fixtures — MinIO small-inline, MinIO versioned (two object versions + a delete marker), MinIO large multipart, a legacy V1 (xl.json-derived) object, and a legacy meta_ver 2 object — decodes every version with parts materialized, and asserts validate_for_metadata_read() is Ok for each. Reverting the tolerant handling (delete-marker shape, legacy per-part checksums, string/short transitioned-versionID, negative actual_size) turns this red. * fix(ci): remove duplicate storage test re-exports --------- Co-authored-by: overtrue <anzhengchao@gmail.com>	2026-07-19 21:52:31 +08:00
houseme	21049401fa	fix(ilm): harden tier transition failure boundaries (#5031) ... * fix(tier): fence generation-scoped operations Refs rustfs/backlog#1354 Co-Authored-By: heihutu <heihutu@gmail.com> * fix(ilm): verify transition upload streams Refs rustfs/backlog#1353 Co-Authored-By: heihutu <heihutu@gmail.com> * test(ecstore): expand transition fault matrix Refs rustfs/backlog#1355 Co-Authored-By: heihutu <heihutu@gmail.com> --------- Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-19 10:48:32 +00:00
Zhengchao An	cf9e9c6fd5	fix(ilm): implement expire_restored delete semantics for restore expiry (#4950) ... DeleteRestoredAction is supposed to demote a restored object back to its pure transitioned state: remove only the local restored copy, strip the x-amz-restore headers, and leave the version (and the remote tier data) untouched. expire_transitioned_object set opts.transition.expire_restored accordingly, but no delete path ever read the flag, so delete_object ran an ordinary delete: on unversioned buckets the whole object vanished and the free-version record scheduled remote tier cleanup (tier data loss); on versioned buckets the latest version got a spurious delete marker that replication propagated. Route expire_restored explicitly in SetDisks::delete_object before delete-marker resolution and replication dispatch: target the found version with FileInfo.expire_restored=true and return early. The FileMeta::delete_version layer already implements the semantics (strip restore headers, keep the version, hand back the local data dir); this wires it up. Also fix the action matching in expire_transitioned_object (extracted into transitioned_object_delete_opts): DeleteRestoredVersionAction previously fell through to the full transitioned-object delete, which removed the remote tier data of a noncurrent restored version. It now routes through the same restored-copy cleanup with the exact version id, matching MinIO's Action.DeleteVersioned()/DeleteRestored() dispatch. Re-enable test_restore_chain_local_read_expiry_keeps_remote_and_allows_ re_restore in the ILM Integration (serial) lane; add unit tests pinning the event->options routing and the filemeta expire_restored branch. Closes rustfs/backlog#1302	2026-07-18 02:55:29 +00:00
houseme	13bdca6762	build(toolchain): switch Rust channel to stable (#4775) ... * Change Rust toolchain channel to stable Signed-off-by: houseme <housemecn@gmail.com> * style: apply clippy --fix and cargo fix lint suggestions Run `cargo clippy --fix --all-targets --all-features` and `cargo fix --lib --all-targets` across the workspace, then resolve the remaining warnings by hand: - collapse needless borrows in `format!` args, prefer `?` over explicit early returns, and use `.values()` / `.flatten()` iterator adapters - rewrite the `Md5` scan loop via `manual_flatten` and re-indent the `select!` macro body (rustfmt skips macro interiors) - annotate the intentional dead-code `Md5` inherent methods (constructed only by the test factory) with `#[allow(dead_code)]` Behavior is unchanged. Co-Authored-By: heihutu <heihutu@gmail.com> --------- Signed-off-by: houseme <housemecn@gmail.com> Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-12 18:59:43 +08:00
houseme	608ab14d7d	perf(ecstore): fold metadata read open+fstat+read into a single spawn_blocking (HP-12 item 1) (#4554) ... Sub-change A only: the two local-disk metadata read paths (`read_metadata_with_dmtime`, `read_all_data_with_dmtime` in crates/ecstore/src/disk/local.rs) previously dispatched open, fstat and the xl.meta read as three separate async fs hops (three spawn_blocking round-trips under tokio::fs). Each is now folded into a single tokio::task::spawn_blocking closure using std::fs, cutting per-metadata-read dispatch from 3 to 1. This does NOT touch sub-change B (removing the entry-point access() call). Correctness first: this is the hottest metadata read path, so the refactor preserves byte-for-byte-equivalent Results. Every error mapping is kept identical: - open failure -> to_file_error - is_dir -> Error::FileNotFound (not to_file_error(EISDIR)) - metadata failure -> to_file_error - xl.meta parse -> propagated verbatim from the parser - try_reserve -> Error::other - read_to_end -> to_file_error For read_all_data_with_dmtime the async NotFound -> access(volume_dir) -> VolumeNotFound fallback (and its warn! event) is preserved on the async side: the closure returns the raw open error unmapped; only open() can yield ENOENT once the fd is valid, so gating the fallback on the open error is equivalent to the original open-arm-only fallback. To run the parser inside a blocking closure, filemeta gains a synchronous twin `read_xl_meta_no_data_sync` (+ `read_more_sync`) in crates/filemeta/src/filemeta/version.rs that line-for-line mirrors the async version, differing only in std vs tokio read_exact. A new equivalence test (`read_xl_meta_sync_equivalence_tests`) feeds identical buffers to both the async and sync readers and asserts equal Ok bytes / equal Err variants across: v1.0; v1.1/v1.2/v1.3; large meta triggering read_more; header truncation -> UnexpectedEof; CRC-trailer truncation -> FileCorrupt; unknown major/minor -> InvalidData; and want boundaries (exact fit, inline-data drop, read_more EOF). Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-08 18:28:57 +00:00
houseme	f96314a1d5	docs(ecstore): pin streaming-only bitrot layout invariant (ECA-18) (#4553) ... bitrot_shard_file_size only counts per-block checksum bytes for the two streaming Highway variants, while BitrotWriter::write interleaves a hash for any hash_algo.size() > 0 and bitrot_verify's read loop assumes an interleaved hash per block. The three disagree for non-streaming algorithms (SHA256/HighwayHash256/BLAKE2b512/Md5), but the divergence is unreachable in production: every write path hardcodes HighwayHash256S and ErasureInfo::get_checksum_info defaults to HighwayHash256S. Per the audit decision (backlog#959), do NOT change the size formula: it is a byte-for-byte port of MinIO's bitrotShardFileSize and its bare return for non-streaming algorithms is correct for MinIO whole-file bitrot; changing it would break legacy interop. Instead, document the per-algorithm layout contract at bitrot_shard_file_size, BitrotWriter, and bitrot_verify, and add regression tests that pin the invariants: get_checksum_info defaults to HighwayHash256S, and the size formula counts per-block hash bytes for streaming variants only while returning the bare size for non-streaming ones. No disk layout or formula change. Co-authored-by: heihutu <heihutu@gmail.com>	2026-07-08 18:25:05 +00:00