Skip to content

Conversation

@squadgazzz
Copy link
Contributor

@squadgazzz squadgazzz commented Aug 28, 2025

Updates aws dependencies to the latest versions. Another requirement for the cowprotocol/services transition to allloy is that it uses AWS v1 which is incompatible with the v0.x used in this repository.

@squadgazzz squadgazzz marked this pull request as ready for review August 28, 2025 14:49
Copilot AI review requested due to automatic review settings August 28, 2025 14:49
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Updates AWS SDK dependencies from v0.x to v1.x versions to maintain compatibility with the cowprotocol/services transition to alloy, which requires AWS v1.

  • Updates aws-config from version 0.55 to 1.8
  • Updates aws-sdk-kms from version 0.28 to 1.85
  • Updates AWS configuration loading code to use the new v1 API pattern

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
ethcontract/Cargo.toml Updates AWS dependency versions to v1.x
examples/examples/kms.rs Updates AWS config loading to use new v1 API with BehaviorVersion

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@socket-security
Copy link

socket-security bot commented Aug 28, 2025

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

@squadgazzz squadgazzz merged commit c9ec7c0 into main Sep 3, 2025
6 checks passed
@squadgazzz squadgazzz deleted the update-aws-libs branch September 3, 2025 06:59
squadgazzz added a commit to cowprotocol/services that referenced this pull request Sep 3, 2025
# Description
Adds a conversion from `ethcontract::Account` to the corresponding alloy
types. A wrapper is introduced because local accounts don’t share a
common type with KMS or PrivateKey in alloy. The usage also differs when
building/signing transactions: for a local account it’s enough to just
set the from field (an address), while with KMS and PrivateKey there
isn’t a direct way to use a signer that’s different from the provider’s
configured one(more details
alloy-rs/alloy#2829).

`ethcontract::Account::Locked` remains unused in this repo and it seems
like there is no direct way to convert it into
`alloy::signers::local::LocalSigner`, so this branch is `unimplemented`.

This PR also depends on
cowprotocol/ethcontract-rs#981, which explains
incompatibilities.

After ethcontract was updated in
cowprotocol/ethcontract-rs#981, driver tests
started failing with stack overflow. As @jmg-duarte's research showed,
that the issue lies in how updated third-party libraries optimizations
work, which is not related to any infinite recursion. The problem
doesn't exist when building with the `--release` flag, so instead, the
stack size was increased.

## How to test
In the upcoming PRs.

---------

Co-authored-by: MartinquaXD <martin.beckmann@protonmail.com>
m-sz pushed a commit to cowprotocol/services that referenced this pull request Sep 4, 2025
# Description
Adds a conversion from `ethcontract::Account` to the corresponding alloy
types. A wrapper is introduced because local accounts don’t share a
common type with KMS or PrivateKey in alloy. The usage also differs when
building/signing transactions: for a local account it’s enough to just
set the from field (an address), while with KMS and PrivateKey there
isn’t a direct way to use a signer that’s different from the provider’s
configured one(more details
alloy-rs/alloy#2829).

`ethcontract::Account::Locked` remains unused in this repo and it seems
like there is no direct way to convert it into
`alloy::signers::local::LocalSigner`, so this branch is `unimplemented`.

This PR also depends on
cowprotocol/ethcontract-rs#981, which explains
incompatibilities.

After ethcontract was updated in
cowprotocol/ethcontract-rs#981, driver tests
started failing with stack overflow. As @jmg-duarte's research showed,
that the issue lies in how updated third-party libraries optimizations
work, which is not related to any infinite recursion. The problem
doesn't exist when building with the `--release` flag, so instead, the
stack size was increased.

## How to test
In the upcoming PRs.

---------

Co-authored-by: MartinquaXD <martin.beckmann@protonmail.com>
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.

3 participants