Disk buffer for S3 sink is not flushed on graceful termination

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

We use a S3 sink with a disk buffer (see configuration below). When downscaling our Vector StatefulSet from 3 to 2 replicas, we detected in the logs that the S3 sink was not properly terminated (see logs below).

We suspect that disk buffers are not flushed by Vector on termination, because we have a batch.timeout_secs set to 60 minutes, which is way more than Kubernetes termination grace period (180 seconds) or Vector's VECTOR_GRACEFUL_SHUTDOWN_LIMIT_SECS (160 seconds).

2026-07-07T16:26:03.699847Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="s3-logs" time_remaining="49 seconds left"
2026-07-07T16:26:18.699770Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="s3-logs" time_remaining="34 seconds left"
2026-07-07T16:26:28.699804Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="s3-logs" time_remaining="24 seconds left"
2026-07-07T16:26:38.699876Z  INFO vector::topology::running: Shutting down... Waiting on running components. remaining_components="s3-logs" time_remaining="14 seconds left"
2026-07-07T16:26:53.699246Z ERROR vector::topology::running: components="s3-logs" Failed to gracefully shut down in time. Killing components. internal_log_rate_limit=false
2026-07-07T16:26:53.699279Z  INFO vector: Vector has stopped.
2026-07-07T16:26:53.699301Z  INFO vector::api::grpc_server: GRPC API server shutting down.

Expected behavior: a new object is pushed in the S3 Bucket when Vector terminates gracefully (rollout, upscale/downscale, config change...)

Workaround: When reducing the batch.timeout_secs to 30 seconds (lower than grace period), Vector shuts down gracefully the component, but as a result we have way more objects pushed in our bucket, which increases cost (we avoid pushing small files with S3 Glacier storage class).

Configuration

    sinks:
      s3-logs:
        type: aws_s3
        inputs:
          - s3-parquet-logs.prod
        region: us-east-1
        bucket: "BUCKET_NAME"
        # ... snip ... (parquet encoding configuration)
        buffer:
          type: "disk"
          max_size: 1073741824 # 1 GB
          when_full: "block"
        batch:
          max_bytes: 62914560 # ~60 MB uncompressed
          timeout_secs: 3600 # 60 minutes

Version

vector 0.56.0 (aarch64-unknown-linux-gnu 6817c02 2026-06-03 14:25:37.451398530)

Debug Output

Example Data

No response

Additional Context

Vector is running on Kubernetes, with the Aggregator role (StatefulSet), with a PVC (EBS GP3) of 2 GB for each Vector pod.

We detected the problem when downscaling our STS from 3 to 2 replicas and reading the logs of the vector-2 pod (the only one terminating during the downscale).

References

• #19600: should be resolved with Vector 0.56.0 but it does not seem to be the case

Start with the aws_s3 sink and its disk-buffer shutdown path, using the provided configuration with a long batch timeout and a graceful termination. Reproduce the Kubernetes-style shutdown and inspect whether buffered data is flushed before the component is killed; done when termination reliably pushes a new S3 object without requiring a short batch timeout.