mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-03 06:37:34 +08:00
32eb116cbc
DeleteBucket answers from a raw per-disk residue scan rather than from a listing, so it can refuse for a reason no S3 request can observe: the client drains every version the API will show, DeleteBucket still returns BucketNotEmpty, and the client-visible message is the generic "The bucket you tried to delete is not empty" for every blocker kind. The server does know which residue blocked it, and where — that is what `bucket_delete_blocked` carries. But it was emitted at `debug`, below both the `error` DEFAULT_LOG_LEVEL and the `info` the CI s3-tests lane runs at, so it was never actually written down. An intermittent BucketNotEmpty in that lane leaves a server log with no trace of the refusal at all, which is not a diagnosable state: confirmed against the artifact log of a failing run, where the rejected bucket appears only in span-close lines and the blocker event is absent entirely. Split the blocker kinds by whether the client can still reach the residue. A visible version or a tier free-version is an ordinary 409 — the bucket really is not empty and the caller can list and delete what is left — so that stays at `warn`. UnknownXlMeta, OrphanDirectory, and DiagnosticBudgetExceeded are on-disk state no S3 request can remove; that is a server-side integrity problem and is now reported at `error`, with the blocker kind, the residue counts, and the sample path. This does not change what DeleteBucket accepts or rejects, and does not retry or suppress anything — it makes the existing diagnosis reachable. Refs #7005, #7010