fix(aws_S3 source): Add timeout for aws operations.#25873
fix(aws_S3 source): Add timeout for aws operations.#25873petere-datadog wants to merge 12 commits into
Conversation
The aws_s3 source created its S3 client with no read or operation timeout (only the SDK-default ~3.1s connect timeout). A half-open or silently dropped connection -- for example one reaped by a NAT gateway idle timeout -- could therefore hang a polling task indefinitely on the GetObject response-body read, stopping SQS polling entirely and stalling S3-based ingestion until the process was restarted. Retries are disabled on this client, so there was no recovery. Apply default S3 client timeouts (connect_timeout_seconds=5, read_timeout_seconds=30) and expose them as source configuration. The read timeout is applied per-read, so a slow but steadily progressing transfer of a large object is not cut off; no operation timeout is set by default to avoid capping legitimately long transfers. This mirrors the existing SQS client timeout support on the same source. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ik/aws-read-timeout
Error logs for failed S3 events only included the SQS message ID, making it hard to tell which S3 object actually failed without cross-referencing. Log the object key (when known) alongside the error at error level.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 644e4cd109
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 273a0fd98a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| AwsTimeout::new( | ||
| configured | ||
| .connect_timeout() | ||
| .or(Some(DEFAULT_S3_CONNECT_TIMEOUT_SECONDS)), |
There was a problem hiding this comment.
Question is this default value how the code behaved previously? If not then maybe we would consider doing nothing if the optional is not filled. Many other integrations do this instead of falling back to a hardcoded default.
There was a problem hiding this comment.
So the default value before was 3.1 seconds https://github.com/awslabs/aws-sdk-rust/blob/33a43d1891b5ae5f5c3ed83343193967c7e01446/sdk/aws-smithy-runtime/src/client/defaults.rs#L38 now we're setting it to 5 seconds. Read timeout wasn't set at all so we're setting it to 30seconds which I think is a good default, cause if the connection is stuck, i.e we've connected but no data is coming across then we shouldn't hang indefinitely.
There was a problem hiding this comment.
Hmm i see. This can go down two paths either:
- we are ok with whatever default the provider ships in their library
- we are not ok and we think 5s is a better choice.
If we go with (1) then my previous suggestion works. If (2) then I think the conventional way to do this in vector is with the #[serde(default) = "xyz"] configurable component tag.
There was a problem hiding this comment.
alright made a larger update, looks like a lot but it's all kinda samey, decided to add timeouts to all the other AWS integrations as well.
…ents Extend the connect/operation/read timeout options previously only available on the aws_s3 source to the aws_cloudwatch_logs, aws_cloudwatch_metrics, aws_kinesis_firehose, aws_kinesis_streams, aws_s3, aws_sns, and aws_sqs sinks, the aws_sqs source, and the aws_secrets_manager secrets backend (as client_timeout, to avoid a naming collision with the exec backend's unrelated timeout field). Also fixes AwsTimeout's Default impl to match its serde field defaults (connect_timeout_seconds=5, read_timeout_seconds=30) instead of silently defaulting to 0.
…ik/aws-read-timeout
Fold the aws_s3-source-only fix fragment into the enhancement fragment now that timeout settings cover all AWS-backed components.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ef846b98d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| timeout_config_builder | ||
| .set_operation_timeout(operation_timeout.map(Duration::from_secs)) | ||
| .set_connect_timeout(Some(Duration::from_secs(connect_timeout))) | ||
| .set_read_timeout(Some(Duration::from_secs(read_timeout))); |
There was a problem hiding this comment.
Avoid forcing first-byte timeout on slow uploads
With the new defaults, every AWS client now gets a 30s read_timeout even when the component config does not opt in. That timeout is documented in AwsTimeout as time to the first response byte from request start, so for sinks that upload request bodies—especially aws_s3 with large batches or slow/S3-compatible endpoints—the response headers may legitimately arrive only after more than 30s of uploading/service work, causing previously valid writes to time out and retry indefinitely unless users discover and raise this new setting. Consider not applying a default read timeout to upload-oriented clients, or making the default opt-in/large enough for existing sink workloads.
Useful? React with 👍 / 👎.
Summary
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
Notes
@vectordotdev/vectorto reach out to us regarding this PR.pre-pushhook, please see this template.make fmtmake check-clippy(if there are failures it's possible some of them can be fixed withmake clippy-fix)make testgit merge origin masterandgit push.Cargo.lock), pleaserun
make build-licensesto regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.