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
Open
No activity in this phase yet.
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.