[storage] Add configurable S3 read timeout (OSMO_S3_READ_TIMEOUT)#1060
[storage] Add configurable S3 read timeout (OSMO_S3_READ_TIMEOUT)#1060xutongNV wants to merge 1 commit into
Conversation
The S3 client (also used for Swift via its S3-compatible API) never set a read_timeout, so botocore's 60s default applied. For large single-PUT objects on backends like Swift, the server replicates and checksums the whole object before responding, which can exceed 60s. The client then raises ReadTimeoutError and retries the entire upload, looping indefinitely even though the bytes transferred fine. Add a configurable read_timeout (env OSMO_S3_READ_TIMEOUT, default 5m) to the botocore Config, mirroring the existing _get_s3_timeout pattern. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds configurable S3 read timeout support via a new ChangesS3 Read Timeout Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1060 +/- ##
=======================================
Coverage 49.07% 49.07%
=======================================
Files 220 220
Lines 28664 28667 +3
Branches 4288 4288
=======================================
+ Hits 14066 14069 +3
Misses 13935 13935
Partials 663 663
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Problem
The S3 client — also used for Swift via its S3-compatible API — never sets a
read_timeout, so botocore's 60s default applies (_get_boto_configinsrc/lib/data/storage/backends/s3.py).For a large object uploaded as a single PUT (i.e. below
multipart_threshold, default 512 MiB), the bytes transfer quickly but the server (e.g. Swift) replicates and checksums the whole object before responding. On a busy/slow backend that finalization exceeds 60s, so botocore raisesReadTimeoutErrorand the upload is retried in full — looping indefinitely even though the data transferred fine.Observed symptom (480 MB upload to
swift://):Fix
Add a configurable
read_timeoutto the botocoreConfig, controlled by a newOSMO_S3_READ_TIMEOUTenv var (default 5m), mirroring the existing_get_s3_timeout()/OSMO_S3_TIMEOUTpattern. This applies to all S3-family backends (S3, Swift, GS, TOS).Changes
s3.py: newOSMO_S3_READ_TIMEOUTconstant,_get_s3_read_timeout()helper, andread_timeoutadded to the botoConfig.test_backends.py: tests for the default (300s) and env override.Testing
Passes, including mypy.
🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
Tests