What this family covers
Thirty-one codes across three classes, all about buckets, objects and Object Lock in your customer's client area — see "What Your Customer Sees" in this category for the panels these faults surface in. This is the family most likely to be about your customer's own data doing something specific, not a fault in this module.
The gateway's own eighteen faults, and three answers that are not faults at all (S3\S3Fault)
gateway_not_reached, sdk_absent and unreachable are all "nothing you can conclude about the customer's data": something other than the object gateway answered, the SDK itself was not found on this server, or no response arrived at all. gateway_error is the object gateway reporting its own fault with a request id, and is also this class's explicit catch-all for anything it has never seen before — report it with that request id rather than guessing which named fault it resembles.
account_suspended matters enough to say plainly: the storage platform answers a suspended account with what looks exactly like a maintenance page, and this must never be reported to the customer as "the platform is down". Unsuspending the service is the only fix; retrying or raising a vendor incident both waste time on a working platform.
wrong_region_for_key and access_denied are both about a key the gateway recognises in some sense: the first means the key does not exist at that gateway at all (almost always the right key sent to the wrong region), the second means the key is known and the operation was refused on scope. not_offered means the gateway does not implement that operation at all — permanent and never retryable, which is why public bucket access is not offered on this platform. no_such_bucket is often not an error at all — it is the expected answer to "does this exist yet?".
bucket_not_empty is worth extra care because its own name is measured to be wrong: this platform has deleted non-empty buckets without refusal, including ones holding multiple versions and an incomplete multipart upload. The one measured trigger for this refusal is an object version under an active Object Lock retention — check retained_until before assuming emptying will help, because it will not. lock_not_available_after_create is a different bucket problem entirely: Object Lock cannot be added after a bucket already exists, the bucket itself is not missing, and a new Object-Lock-enabled bucket is the only way forward. retained_until and bypass_refused both concern a live retention: there is no override on this platform in either governance or compliance mode, from this module or anyone else, and a retention does not survive the service being cancelled — a genuinely important thing for a customer relying on it to know up front.
delete_not_effective means a delete reported success and a re-listing disagrees; do not report the bucket as emptied. bucket_name_refused is this module refusing a name before any request is sent, stricter than the gateway itself, because a name the gateway would accept can still be unreachable in a tool that addresses a bucket as a hostname. budget_exhausted means a bounded operation stopped at its limit, incomplete but not broken; run it again. credential_missing means no key exists for the region an operation needs — a key from one region is never valid in another. upload_corrupted is the newest fault in this vocabulary: the gateway recomputed an upload's checksum, it did not match, and the object was never stored — this is damage between the customer's disk and the wire, not a platform fault, and the fix is simply to send it again.
Three outcomes are explicitly not faults, and a caller that treats them as one is the bug: partial_delete (a batch delete succeeded overall and named which keys it could not clear — do not retry those one at a time, it fails identically), cors_not_configured and versioning_not_configured (both the ordinary read-back of a fresh bucket with nothing configured yet).
Folder and object names refused before anything is sent (S3\ObjectKeyError, six codes)
prefix_absolute, prefix_traversal, prefix_control_character, prefix_too_long and prefix_empty all concern a folder path typed into the client-area browser; key_empty concerns the object name itself. Every one of these is a customer-fixable input problem — rename the folder or object per the rule named — and none of them ever reaches the gateway, so none of them can have partially happened.
Object Lock's own internal guards (S3\ObjectLockError, four codes, none actionable)
acknowledgement_unattributed, acknowledgement_no_fingerprint, acknowledgement_no_bucket and acknowledgement_bad_time all guard the record this module writes when a customer accepts the Object Lock disclosure before an Object-Lock-enabled bucket is created. Every one of them means "no bucket was created" and every one of them is an internal consistency check on this module's own code, not something a customer can trigger by clicking through the form normally. If you see one, report it with the code.
How a raw gateway response becomes one of the eighteen names above
S3\S3FaultMapper is the classifier that turns a status code, a body and a header set into one of the fault or non-fault names above; it declares no fault codes of its own. The one thing worth knowing about it: a 503 from this gateway carries no error code at all when an account is suspended, so the mapper discriminates on the HTTP status and the absence of a request id, not on any code — which is exactly why account_suspended must never be confused with an ordinary gateway error.