Skip to main content
← Back to list
01Issue
BugOpenExtensionsPublic
AssigneesNone

Relationships

#2592 s3-datastore: SWAMP_S3_REQUEST_TIMEOUT_MS does not appear to apply to ListObjectsV2 during pull

Opened by hammz · 9/28/2026

Observation

While reproducing swamp-club#2553 against MinIO behind a proxy that delayed ListObjectsV2 by 65s, SWAMP_S3_REQUEST_TIMEOUT_MS=120000 was set, but the proxy log showed the delayed list call being re-sent roughly every 30s (the 30s default request timeout). That stretched a single-model pull to ~123s.

@swamp/s3-datastore 2026.09.24.1, swamp 20260928.150833.0-sha.6858940b.

What the code suggests

S3Client reads the env var in its constructor (parseEnvTimeout, accepts 1000 to 600000) and passes it to the AWS SDK as requestHandler.requestTimeout. So either the env value is not reaching the constructor in the bundled extension, or some other timeout (an AbortSignal.timeout on the list path, or the retry layer in s3_cache_sync.ts) applies to list calls.

Root cause not investigated yet. The proxy script and log from the repro can be shared.

Expected

SWAMP_S3_REQUEST_TIMEOUT_MS governs every S3 request, including paginated listAllObjects, or the docs say which calls it does not cover.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

  • Extension: @swamp/s3-datastore@2026.09.24.1
  • swamp: 20260928.150833.0-sha.6858940b
  • OS: linux (x86_64)
  • Deno: 2.9.7
  • Shell: /usr/bin/zsh
02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

9/28/2026, 4:09:55 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

system commented 9/28/2026, 4:09:55 PM

Classified automatically when this issue was filed.

  • Source: Extensions

If you feel this classification is incorrect, add a ripple to tell us so.

Sign in to post a ripple.