Skip to content

Make S3 operation timeout configurable - #53

Merged
louisgls merged 1 commit into
Intrinsec:mainfrom
vetal4444:configurable-s3-timeout
Jul 29, 2026
Merged

Make S3 operation timeout configurable#53
louisgls merged 1 commit into
Intrinsec:mainfrom
vetal4444:configurable-s3-timeout

Conversation

@vetal4444

Copy link
Copy Markdown
Contributor

No description provided.

@louisgls
louisgls merged commit 57f399f into Intrinsec:main Jul 29, 2026
@louisgls

Copy link
Copy Markdown
Collaborator

Merged in #55 as part of the v1.9.0 release. Straightforward change, and moving the bound out of a compile-time constant was overdue.

One thing worth reconsidering: an out-of-range value silently falls back to the default.

v := time.Duration(c.k.Int64(key)) * time.Second
if v <= 0 || v > MaxS3OperationTimeout {
    return DefaultS3OperationTimeout
}

An operator who sets S3PROXY_S3_OPERATION_TIMEOUT=3600 (a plausible guess for "one hour") gets 120 seconds, with nothing in the logs saying so. They will most likely discover it from timeouts in production rather than from the config. The same applies to a typo that fails to parse as an int64 — koanf yields 0, which also lands on the default.

Either a log.Warn at startup or a hard failure in Validate() would make the misconfiguration visible. Given that the other bounded knobs in this file (MaxPutBodySize, MultipartMaxSize) follow the same silent-clamp pattern, a single consistent treatment across all of them would probably be the cleaner fix.

Also a heads-up for anyone rebasing onto main: this PR removed the s3OperationTimeout constant from object.go, and #52 adds a new use of it in handler_multipart.go. Git merges both without reporting a conflict, but the result does not compile — see the note on #52.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants