Postconditions: what we check

• send · s3-object-operation-no-try-catch

  error
  Whens3Client.send() called with object operation commands without try-catch
  ThrowsNoSuchKey (404), AccessDenied (403), NoSuchBucket (404), network errors
  Required handlingMUST wrap await s3Client.send() in try-catch block when using GetObjectCommand, PutObjectCommand, DeleteObjectCommand, HeadObjectCommand, or CopyObjectCommand. Catch block should check error.name for specific error types (NoSuchKey, AccessDenied, NoSuchBucket) and handle appropriately.
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• send · s3-multipart-no-try-catch

  error
  Whens3Client.send() called with multipart commands without try-catch
  ThrowsNoSuchUpload (404), EntityTooSmall (400), InvalidPart (400)
  Required handlingMUST wrap multipart upload operations in try-catch block. Catch block MUST call AbortMultipartUploadCommand with the uploadId to clean up orphaned parts. This prevents storage charges for incomplete uploads.
  costhighin prodsilent failureusers seelost datavisibilitysilent
  Sources[2]
• send · s3-bucket-operation-no-try-catch

  error
  Whens3Client.send() called with bucket operations without try-catch
  ThrowsBucketAlreadyExists (409), BucketNotEmpty (409), NoSuchBucket (404)
  Required handlingMUST wrap bucket operations in try-catch block. Handle BucketAlreadyExists/BucketAlreadyOwnedByYou gracefully (may be acceptable), check BucketNotEmpty before deletion, validate permissions.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[3]
• send · s3-list-operation-no-try-catch

  warning
  Whens3Client.send() called with list operations without try-catch
  ThrowsNoSuchBucket (404), AccessDenied (403), InvalidArgument (400)
  Required handlingSHOULD wrap list operations in try-catch block for robustness. Handle NoSuchBucket and AccessDenied errors gracefully. Implement pagination properly with ContinuationToken.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• S3Client · s3-client-no-retry-config

  info
  WhenS3Client created without retry configuration
  Required handlingCONSIDER configuring retry settings: new S3Client({ region, maxAttempts: 3, retryMode: 'adaptive' }). Adaptive mode adjusts retry attempts based on throttling signals from AWS.
  costlowin proddegraded serviceusers seedegraded performancevisibilityvisible
  Sources[4]
• S3Client · s3-client-missing-region

  warning
  WhenS3Client created without explicit region
  Required handlingSHOULD explicitly set region: new S3Client({ region: 'us-east-1' }) or use environment variable with fallback.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• DeleteObjectsCommand · s3-batch-delete-errors-not-checked

  error
  Whens3Client.send(DeleteObjectsCommand) is called and the response.Errors array is not checked after the await resolves
  ThrowsS3ServiceException (for auth/request failures); individual object errors are in response.Errors[]
  Required handlingMUST check response.Errors after every DeleteObjectsCommand call. If response.Errors && response.Errors.length > 0, handle each failed key individually. Do not assume all objects were deleted just because the command did not throw.
  costhighin prodsilent failureusers seelost datavisibilitysilent
  Sources[5]
• DeleteObjectsCommand · s3-batch-delete-quiet-mode-unchecked

  warning
  WhenDeleteObjectsCommand is called with Delete.Quiet: true and response.Errors is not checked after the await
  Throwsresponse.Errors[] contains deletion failures (not thrown)
  Required handlingSHOULD check response.Errors even in Quiet mode. If response.Errors has entries, log failed keys and handle appropriately. Consider using verbose mode (Quiet: false) in non-performance-critical paths to get full deletion confirmation.
  costmediumin prodsilent failureusers seelost datavisibilitysilent
  Sources[5]
• waitUntilObjectExists · s3-waiter-timeout-not-handled

  error
  WhenwaitUntilObjectExists() is called without a try-catch block and the object does not appear within maxWaitTime seconds
  ThrowsTimeoutError (error.name === 'TimeoutError') from @smithy/util-waiter
  Required handlingMUST wrap waitUntilObjectExists in try-catch. Check error.name === 'TimeoutError' to distinguish timeout from other failures. Return a meaningful error to the caller rather than propagating the raw TimeoutError.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• waitUntilObjectExists · s3-waiter-abort-not-handled

  warning
  WhenwaitUntilObjectExists() is called with an AbortSignal and the signal is triggered before the waiter completes, without try-catch handling AbortError
  ThrowsAbortError (error.name === 'AbortError') from @smithy/util-waiter
  Required handlingSHOULD handle AbortError separately from TimeoutError in catch block. AbortError means intentional cancellation; TimeoutError means capacity issue. Treat AbortError as a clean cancellation, not a failure.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• waitUntilBucketExists · s3-bucket-waiter-timeout-not-handled

  error
  WhenwaitUntilBucketExists() is called without a try-catch block and the bucket does not become accessible within maxWaitTime seconds
  ThrowsTimeoutError (error.name === 'TimeoutError') from @smithy/util-waiter
  Required handlingMUST wrap waitUntilBucketExists in try-catch. Handle TimeoutError by retrying with increased maxWaitTime or surfacing a meaningful error. Do not assume bucket creation is always fast — cross-region propagation adds latency.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1]
• AbortMultipartUploadCommand · s3-abort-multipart-no-try-catch

  error
  Whens3Client.send(AbortMultipartUploadCommand) is called without try-catch, especially inside a catch block of a failed multipart upload flow
  ThrowsNoSuchUpload (404) when UploadId is invalid, expired, or already completed
  Required handlingMUST wrap AbortMultipartUploadCommand in try-catch when used in cleanup paths. Handle NoSuchUpload gracefully (the upload may have already been cleaned up). Log the abort failure but do not let it mask the original error.
  costmediumin prodsilent failureusers seelost datavisibilitysilent
  Sources[6]
• AbortMultipartUploadCommand · s3-abort-multipart-in-flight-parts

  warning
  WhenAbortMultipartUploadCommand is called once without verifying all parts are freed, when concurrent part uploads may still be in flight
  ThrowsS3 does not throw — parts may remain and incur storage charges silently
  Required handlingSHOULD call ListPartsCommand after AbortMultipartUpload to verify all parts are freed. If parts remain, retry the abort. This prevents ongoing storage charges for abandoned upload parts.
  costmediumin prodsilent failureusers seelost datavisibilitysilent
  Sources[6]
• RestoreObjectCommand · s3-restore-object-no-try-catch

  error
  Whens3Client.send(RestoreObjectCommand) is called without try-catch
  ThrowsObjectAlreadyInActiveTierError (409) when object is in active tier; RestoreAlreadyInProgress (409) when restore is already running
  Required handlingMUST wrap RestoreObjectCommand in try-catch. Handle ObjectAlreadyInActiveTierError gracefully (object is already accessible, no restore needed). Handle RestoreAlreadyInProgress as informational (check restore status before retrying).
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[7]
• RestoreObjectCommand · s3-restore-expedited-unavailable

  warning
  WhenRestoreObjectCommand is called with GlacierJobParameters.Tier: 'Expedited' without fallback handling for capacity unavailability
  ThrowsGlacierExpeditedRetrievalNotAvailable (503) when expedited capacity is insufficient
  Required handlingSHOULD catch GlacierExpeditedRetrievalNotAvailable and retry with Tier: "Standard" as fallback. Do not surface expedited-specific errors to end users — fall back silently to Standard tier.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[7]
• waitUntilObjectNotExists · s3-object-not-exists-waiter-timeout-not-handled

  error
  WhenwaitUntilObjectNotExists() is called without a try-catch block and the object remains visible past maxWaitTime seconds
  ThrowsTimeoutError (error.name === 'TimeoutError') from @smithy/util-waiter
  Required handlingMUST wrap waitUntilObjectNotExists in try-catch. Check error.name === 'TimeoutError' to distinguish timeout from other failures. Surface a meaningful error to the caller (e.g. "object still visible after N seconds — manual verification required") rather than propagating the raw TimeoutError. Do not silently swallow — that hides eventual-consistency issues from operators.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1][8]
• waitUntilObjectNotExists · s3-object-not-exists-waiter-abort-not-handled

  warning
  WhenwaitUntilObjectNotExists() is called with an AbortSignal and the signal is triggered before the waiter completes, without try-catch handling AbortError
  ThrowsAbortError (error.name === 'AbortError') from @smithy/util-waiter
  Required handlingSHOULD handle AbortError separately from TimeoutError in catch block. AbortError means intentional cancellation (treat as clean cancellation, not a failure). TimeoutError means the object did not disappear in time (treat as eventual-consistency lag — surface to operator).
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1][8]
• waitUntilBucketNotExists · s3-bucket-not-exists-waiter-timeout-not-handled

  error
  WhenwaitUntilBucketNotExists() is called without a try-catch block and the bucket remains visible past maxWaitTime seconds
  ThrowsTimeoutError (error.name === 'TimeoutError') from @smithy/util-waiter
  Required handlingMUST wrap waitUntilBucketNotExists in try-catch. Handle TimeoutError by retrying with increased maxWaitTime or surfacing an operator-visible error. Do not silently swallow — leaked buckets accrue storage costs and may cause naming collisions in CI test runs.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[1][8]

Sources

Every postcondition cites at least one of these. Grouped by source type; numbered to match the footnotes above.

Research notes

Curator notes from SOURCES.md captured when the profile was written so you can verify the reasoning, not just the rules.