build(deps): bump the simple1 group across 1 directory with 8 updates

[dependabot]

Bumps the simple1 group with 1 update in the / directory: aws-config.

Updates aws-config from 1.8.13 to 1.8.15

Commits

• See full diff in compare view

Updates aws-credential-types from 1.2.11 to 1.2.14

Commits

• See full diff in compare view

Updates aws-types from 1.3.11 to 1.3.14

Commits

• See full diff in compare view

Updates aws-smithy-runtime-api from 1.11.3 to 1.11.6

Commits

• See full diff in compare view

Updates aws-smithy-runtime from 1.10.0 to 1.10.3

Commits

• See full diff in compare view

Updates aws-smithy-types from 1.4.3 to 1.4.7

Commits

• See full diff in compare view

Updates aws-sigv4 from 1.3.8 to 1.4.2

Changelog

Sourced from aws-sigv4's changelog.

March 16th, 2026

New this release:

• 🐛 (client) Fix null value handling in dense collections: SDK now correctly rejects null values in non-sparse collections instead of silently dropping them.

March 2nd, 2026

New this release:

• 🐛 (client, smithy-rs#4429) Fix bug where initial-request messages in event stream operations are not signed.

February 16th, 2026

New this release:

• 🎉 (server, smithy-rs#4494) Automatically add smithy.framework#ValidationException to operations with constrained inputs. Previously, users had to either set addValidationExceptionToConstrainedOperations: true in codegen settings or manually add ValidationException to each operation. Now this happens automatically unless a custom validation exception (a structure with the @validationException trait) is defined in the model. When using a custom validation exception, users must explicitly add it to each applicable operation. The addValidationExceptionToConstrainedOperations flag is deprecated.

February 10th, 2026

Breaking Changes:

• ⚠️ (all) Upgrade MSRV to Rust 1.91.0.

February 1st, 2026

Breaking Changes:

• ⚠️🎉 (client, smithy-rs#4454, smithy-rs#4467, aws-sdk-rust#1389) Enable retries by default for AWS SDK clients using BehaviorVersion::v2026_01_12() or later.

  Previously, retries were only enabled when constructing clients via aws_config::load_from_env(). Clients constructed directly using Client::from_conf() did not have retries enabled, which was inconsistent with AWS SDK behavior in other languages.

  This change affects AWS SDK clients constructed with Client::from_conf() when using BehaviorVersion::v2026_01_12() or BehaviorVersion::latest(). Generic Smithy clients (non-AWS) are not affected.

  To disable retries:

  let config = aws_sdk_s3::Config::builder()
      .retry_config(RetryConfig::disabled())
      // ...
      .build();

  For more context, see the discussion on retry behavior.

New this release:

• 🎉 (client, smithy-rs#312, @​AmitKulkarni23) Add support for Smithy bigInteger and bigDecimal types as string wrappers in aws-smithy-types, allowing users to parse with their preferred big number library.
• 🎉 (all, smithy-rs#4484) All Smithy-rs crates, for both servers and clients, now use the 1.x version of the http crate for all internal processing. Utility methods are still provided for users to convert between SDK types and both of the http 0.x and 1.x types.
• 🐛 (client, smithy-rs#4500) Fix JMESPath integer literal handling in waiters to support Smithy 1.66.0, which parses integer literals as Long instead of Double.

... (truncated)

Commits

• See full diff in compare view

Updates aws-sdk-sts from 1.97.0 to 1.101.0

Commits

• See full diff in compare view

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).