Files
minio/cmd
Feng Ruohang bd39bab339 test(ilm): cover the history majority, approval check and tier ownership gates
Three safeguards of the lifecycle and tier cleanup paths had no test
that failed when they were removed:

- authoritativeHistory accepts a revision only on more than half of the
  drives. TestPoolsLifecycleHalfDriveMarker holds a delete marker on
  exactly half of sixteen drives, which is the read quorum of a marker,
  and checks that the history is refused, that the expiry of the
  version under it and of the key are refused and every drive keeps what
  it has, and that one more drive decides. With the guard removed the
  strict merge at the same majority still refuses the history; with the
  merge relaxed as well the test fails, so it pins the refusal, not one
  of its two layers.
- deleteAllApproved refuses a purge whose placement read differs from
  the versions it approved. deleteAllBeforePlacement is a test-only
  injection point between the two reads, nil in production.
  TestPurgeAllVersionsRefusesChangedApproval writes a new version and
  rewrites the latest one there, as a writer that bypasses the object
  lock would, and checks the write quorum refusal, the
  history_unavailable count, that nothing is deleted and that the next
  purge removes the key. With the check disabled the purge deletes the
  versions it never approved.
- readTierHistory refuses the ownership of a remote object while a
  drive of any pool cannot be read, and xlMetaV2.DeleteVersion deletes
  a free record only with the remote tuple it names.
  TestTierOwnershipReadFailsClosed fails one drive of the pool that
  holds nothing of the key as offline, not found, faulty and
  unformatted, and checks that the expiry worker's and the
  decommission's cleanup are refused with a read quorum error and
  succeed once the drive reads again.
  TestFreeRecordDeleteNeedsMatchingTuple deletes a free record with
  another tier, remote object and remote version, in memory and on an
  xlStorage drive, and checks the record stays until the tuple matches.
  With either check removed the remote object or the record is deleted.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Feng Ruohang <rh@vonng.com>
2026-11-07 17:04:02 +08:00
..
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-04-09 07:28:39 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-04-09 07:28:39 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-08-28 19:39:48 -07:00
2025-09-28 13:59:21 -07:00
2025-08-28 19:39:48 -07:00