chore(deps): bump alloy-provider from 1.8.3 to 2.0.5#1449
chore(deps): bump alloy-provider from 1.8.3 to 2.0.5#1449dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
❌ Needs Work —
|
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 1 Blocking Finding — 31939aa2
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Latest PR review status: sticky summary
tangletools · 2026-06-03T17:34:00Z · immutable trace
dependabot
Bot
changed the title
dependabot
Bot
force-pushed
the
dependabot/cargo/alloy-provider-2.0.0
branch
from
31939aa to
243c5ad
Compare
✅ No Blockers —
|
| deepseek | glm | aggregate | |
|---|---|---|---|
| Readiness | 76 | 92 | 76 |
| Confidence | 70 | 70 | 70 |
| Correctness | 76 | 92 | 76 |
| Security | 76 | 92 | 76 |
| Testing | 76 | 92 | 76 |
| Architecture | 76 | 92 | 76 |
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
🟠 MEDIUM Potential type mismatch: alloy_network v1.8 used alongside alloy_provider v2.0 re-exports — Cargo.toml
alloy-provider is bumped from 1.8 to 2.0 (line 419), but alloy-network remains pinned at 1.8 (line 423) in the workspace. crates/evm-extra/src/util.rs:1 imports
use alloy_network::EthereumWalletfrom v1.8 and passes it toProviderBuilder::wallet()from alloy_provider v2.0 (line 51). alloy_provider 2.0 depends on alloy-network 2.0 transitively, making itsEthereumWallettype from alloy_network 2.0, not 1.8. In Rust, different major versions produce different type i
🟡 LOW 10 alloy crates now dual-versioned (1.8.x + 2.0.x) in resolved tree — Cargo.lock
After the
alloy-provider 2.0bump, every alloy crate has both a 1.8.x and a 2.0.x entry in the lockfile: alloy-provider, alloy-pubsub, alloy-signer, alloy-transport, alloy-transport-http, alloy-transport-ws, alloy-rpc-client, alloy-network, alloy-consensus, alloy-eips. The workspace Cargo.toml still pinsalloy-pubsub,alloy-signer,alloy-network,alloy-contract,alloy-consensus, andalloy-transportat 1.8 whilealloy-provider 2.0transitively pulls in 2.0 versions of these same crates. This is not a correctness bug (Rust supports this pattern), but it doubles the footprint of the alloy stack in the final binary and increases compile time. Consider bumping all workspace-level alloy deps to 2.0 in a follow-up to deduplicate.
🟡 LOW alloy-transport-ws 2.0.5 pulls in rustls 0.23.38 — Cargo.lock
The new
alloy-transport-ws 2.0.5entry depends onrustls 0.23.38for TLS, which is new to the alloy-2.0 transport chain (the 1.8.xalloy-transport-wsdoes not list rustls directly in its resolved deps). The workspace already hasrustls 0.23elsewhere, so this is not a new crate, but it does mean the alloy WS transport path now carries a TLS dependency. No action needed if thewsfeature is required.
🟡 LOW No compilation verification evidence provided for major version bump — Cargo.toml
alloy-provider is a major semver bump (1.8→2.0) affecting 27 Cargo.toml consumers and 52 .rs files across the workspace. The committed Cargo.lock confirms dependency resolution but not compilation. A
cargo check --workspaceor CI link confirming green build should accompany this change. Alloy 2.0 restructured the provider/filler/network layer — silent API breakage risk is nonzero even without the specific type mismatch finding above.
🟡 LOW alloy-provider 2.0 semver-major bump may break downstream API usage — Cargo.toml
Line 419:
alloy-providerjumps from 1.8 to 2.0 (semver-major). Other alloy crates likealloy-pubsub,alloy-signer,alloy-network,alloy-contractremain at 1.8. If alloy-provider 2.0 removed or renamed public types that downstream crates depend on, compilation will fail. This is a low-severity finding because CI will catch it — not a silent behavioral change. However, the mixed 1.8/2.0 alloy versions should be validated to ensure they're from the same compatible release. Fix: confirm workspace compiles clean (cargo build --workspace --all-features).
tangletools · 2026-06-08T00:08:05Z · trace
tangletools
dismissed
their stale review
Superseded by re-review — no blocking findings on latest commit.
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Approved — 5 non-blocking findings — 243c5ad0
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Summary comment for this run: full summary
tangletools · 2026-06-08T00:08:05Z · immutable trace
Bumps [alloy-provider](https://github.com/alloy-rs/alloy) from 1.8.3 to 2.0.5. - [Release notes](https://github.com/alloy-rs/alloy/releases) - [Changelog](https://github.com/alloy-rs/alloy/blob/main/CHANGELOG.md) - [Commits](alloy-rs/alloy@v1.8.3...v2.0.5) --- updated-dependencies: - dependency-name: alloy-provider dependency-version: 2.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/cargo/alloy-provider-2.0.0
branch
from
243c5ad to
35e8af6
Compare
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🔴 Value Audit — redundant-or-flawed
| Verdict | redundant-or-flawed |
| Concerns | 2 (2 strong-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 674.9s (2 bridge agents) |
| Total | 674.9s |
💰 Value — redundant-or-flawed
Bumps alloy-provider to 2.0.5 while leaving alloy-network and other tightly-coupled alloy crates at 1.8, creating a type-system version skew that will break compilation; should not ship as-is.
- What it does: Changes the workspace alloy-provider requirement from "1.8" to "2.0" in Cargo.toml:419 and regenerates Cargo.lock so workspace crates resolve alloy-provider 2.0.5 instead of 1.8.3. No Rust source files are changed.
- Goals it achieves: Pick up alloy-provider 2.0.5 bug fixes and performance improvements (failed-impersonated-send cleanup, EIP-1559 divide-by-zero fix, txpool deserialization optimization, etc.) and continue migrating the alloy dependency set toward the 2.x line.
- Assessment: The goal is legitimate, but the change is incoherent as-merged. alloy-provider is tightly coupled to alloy-network, alloy-rpc-types-eth, alloy-signer, and alloy-transport; its 2.0 major release reshapes the ProviderBuilder, Network, and transaction-builder APIs. Bumping only alloy-provider while the workspace keeps the rest of the ecosystem at 1.8 forces two parallel major-version copies of those
- Better / existing approach: Coordinate the alloy-provider bump with the rest of the core alloy ecosystem. Cargo.lock at HEAD shows alloy-provider 2.0.5 already pulls in alloy-network 2.0.5, alloy-rpc-types-eth 2.0.5, alloy-signer 2.0.5, etc.; the workspace should bump alloy-network, alloy-rpc-types, alloy-rpc-types-eth, alloy-transport, alloy-signer, alloy-contract, and alloy-consensus to 2.x alongside alloy-provider, then u
🎯 Usefulness — redundant-or-flawed
Bumping alloy-provider to 2.0 while leaving its interoperable alloy companion crates at 1.8 creates a major-version split that the existing call sites cannot satisfy; CI already failed with exit code 101.
- Integration: Wires in at the workspace level — Cargo.toml:419 changes the alloy-provider workspace pin from 1.8 to 2.0, so every crate that consumes alloy-provider via the workspace (e.g., blueprint-client-evm, blueprint-client-tangle, blueprint-manager, blueprint-chain-setup-anvil, blueprint-evm-extra) reaches 2.0. But it does not wire correctly: Cargo.lock at blueprint-client-evm (line 3204) resolves alloy-p
- Fit with existing patterns: Does not fit the codebase's established dependency pattern. The repo uses workspace pins for the alloy family (Cargo.toml:408-428). A few alloy crates were already migrated to 2.0 (alloy-rpc-client, alloy-transport-http, alloy-eips, alloy-signer-aws/gcp), but alloy-provider is the central trait crate that tightly couples to alloy-network and alloy-rpc-types. Bumping only alloy-provider produces a
- Real-world viability: Won't hold up. The PR's GitHub Actions run (#27481536833) shows the Integration Tests job failed with exit code 101 (check-run 81230069562 annotations). Source files mix 2.0 provider imports with 1.8 companion imports in the same module: crates/clients/evm/src/instrumented_client.rs:7 (alloy_provider::Provider/ProviderBuilder/RootProvider) with line 14 (alloy_transport::TransportError) and line 10
💰 Value Audit
🔴 Single-crate alloy 2.0 bump creates type incompatibility with workspace alloy-network 1.8 [better-architecture] ``
Cargo.lock at HEAD shows alloy-provider 2.0.5 depends on alloy-network 2.0.5, alloy-rpc-types-eth 2.0.5, alloy-signer 2.0.5, and alloy-transport 2.0.5, while Cargo.toml keeps alloy-network, alloy-rpc-types-eth, alloy-signer, alloy-contract, and alloy-transport at 1.8. Workspace code crosses these versions in the same compilation unit: crates/clients/tangle/src/client.rs:10 imports alloy_network::Ethereum (1.8.3) and line 12 imports alloy_provider::{DynProvider, Provider, ProviderBuilder} (2.0.5)
🎯 Usefulness Audit
🔴 Major-version alloy split: provider 2.0 paired with network/rpc/transport 1.8 [integration] ``
Cargo.toml:419 bumps alloy-provider to 2.0, but Cargo.toml:412-428 leaves alloy-network (line 423), alloy-rpc-types (line 417), alloy-rpc-types-eth (line 418), alloy-transport (line 427), alloy-pubsub (line 420), alloy-json-rpc (line 412), and alloy-consensus (line 425) at 1.8. Cargo.lock confirms blueprint-client-evm resolves alloy-provider 2.0.5 (line 586) alongside alloy-network 1.8.3 (line 434), alloy-rpc-types-eth 1.8.3, alloy-transport 1.8.3, etc. In Rust these major versions are separate
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
|
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🔴 Value Audit — redundant-or-flawed
| Verdict | redundant-or-flawed |
| Concerns | 3 (1 strong-concern, 2 medium-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 127.2s (2 bridge agents) |
| Total | 127.2s |
💰 Value — better-approach-exists
Bumps alloy-provider to 2.0.5 in isolation, which pulls in a second copy of provider/pubsub/transport-ws plus their transitive v2 deps while the rest of the workspace alloy family stays on 1.8; a coordinated alloy v2 bump is the better approach.
- What it does: Changes the workspace dependency pin of alloy-provider from 1.8 to 2.0 (Cargo.toml:419) and regenerates Cargo.lock so that direct workspace consumers resolve alloy-provider 2.0.5. Because alloy-contract, alloy-network, alloy-pubsub, alloy-signer, alloy-consensus, alloy-transport, alloy-json-rpc, alloy-rpc-types, alloy-rpc-types-eth, and the alloy meta-crate remain pinned at 1.8 (Cargo.toml:409-428
- Goals it achieves: Adopts alloy-provider v2 bug-fixes/perf noted in the release notes (failed impersonated-send cleanup, EIP-1559 divide-by-zero fix, txpool deserialization optimization) and aligns provider with already-upgraded workspace members alloy-rpc-client 2.0, alloy-transport-http 2.0, alloy-eips 2.0, and alloy-signer-aws/gcp 2.0 (Cargo.toml:416-418, 426, 433-434).
- Assessment: The narrow bump works for crates that only use alloy-provider directly, but it is incoherent for the workspace as a whole. Cargo.lock now carries 19 pairs of duplicate alloy crates, up from 16 before the change, and 10 workspace crates depend on both alloy-provider and alloy-contract (e.g. crates/manager/Cargo.toml:40,45; crates/chain-setup/anvil/Cargo.toml:17,18; crates/sdk/Cargo.toml:44). Those
- Better / existing approach: The repo already coordinates related alloy bumps at the workspace root, e.g. commit 7061c5b bundled alloy-eips and alloy-signer-gcp major bumps and verified the workspace built cleanly. The right approach is either to keep alloy-provider at 1.8 until alloy, alloy-contract, alloy-network, alloy-pubsub, alloy-rpc-types, alloy-rpc-types-eth, alloy-signer, alloy-signer-local, alloy-consensus, alloy-tr
🎯 Usefulness — redundant-or-flawed
Bumping alloy-provider alone to 2.x while the rest of the alloy type ecosystem (network, contract, rpc-types, signer, and the alloy umbrella) stays on 1.x forces incompatible duplicate provider types into the build and breaks the type graph the workspace actually uses.
- Integration: The new provider is wired into the workspace at Cargo.toml:419 and is reached by ~20 workspace crates (e.g., cli/Cargo.toml:67, crates/manager/Cargo.toml:40, crates/evm-extra/Cargo.toml:22) and many source call sites (cli/src/command/dev/up.rs:12-14, crates/clients/eigenlayer/src/client.rs:53). However, Cargo.lock now resolves two copies of alloy-provider: 2.0.5 for direct workspace users and 1.8.
- Fit with existing patterns: The codebase already mixes a few alloy 2.x crates (rpc-client, transport-http, eips, signer-aws/gcp), but the core provider-facing types are kept aligned on 1.x: alloy-network=1.8, alloy-contract=1.8, alloy-rpc-types=1.8, alloy-signer=1.8 (Cargo.toml:417-424). The established pattern is to keep interoperable alloy crates on the same major line because they share public types. Bumping only provider
- Real-world viability: Real code paths already pass wallets, transaction requests, contract instances, and providers across crate boundaries. Because Rust treats 1.x and 2.x as distinct crates, these paths will fail to compile when types from alloy-network 1.8 are handed to provider 2.0, which depends on alloy-network 2.0.5 (Cargo.lock:595). The PR contains no source changes to adapt to the 2.0 API, and external depende
🎯 Usefulness Audit
🔴 Partial alloy 2.x bump creates incompatible duplicate provider types [integration] ``
Cargo.toml:419 bumps alloy-provider to 2.0, but Cargo.lock:586-605 shows alloy-provider 2.0.5 depends on alloy-network 2.0.5, alloy-signer 2.0.5, alloy-rpc-types-eth 2.0.5, etc. The workspace still pins those sibling crates to 1.8 (Cargo.toml:417-424). Workspace code imports both, e.g., cli/src/command/dev/up.rs:12-14 uses alloy_network::EthereumWallet and alloy_provider::ProviderBuilder, and crates/clients/eigenlayer/src/client.rs:53 takes an alloy_network::EthereumWallet and returns an alloy_p
🟠 Provider bump is out of step with the established alloy version alignment [fit] ``
The workspace pins alloy as a group at Cargo.toml:409-428, and most provider-facing crates remain on 1.x. blueprint-sdk re-exports alloy 1.8 (crates/sdk/Cargo.toml:44, crates/sdk/src/lib.rs:132), so SDK users will receive provider types from 1.8.3 while direct alloy_provider users receive 2.0.5. This splits the codebase's public surface. Action: align all alloy crate versions (including the sdk re-export) before landing a provider major bump.
💰 Value Audit
🟠 Isolated provider bump fragments the alloy dependency graph [better-architecture] ``
Cargo.toml:419 bumps alloy-provider to 2.0 while Cargo.toml:409-428 leaves alloy, alloy-contract, alloy-network, alloy-pubsub, alloy-signer, alloy-signer-local, alloy-consensus, alloy-transport, alloy-json-rpc, alloy-rpc-types, and alloy-rpc-types-eth at 1.8. As a result Cargo.lock resolves duplicate versions of alloy-provider (lines 540-543 and 586-589), alloy-pubsub (lines ~604-607 and 645-648), and alloy-transport-ws (lines ~1157-1160 and 1235-1238), plus their transitive v2 dependencies. Ten
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
❌ Needs Work —
|
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 1 Blocking Finding — 35e8af69
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Summary comment for this run: full summary
tangletools · 2026-06-14T00:15:43Z · immutable trace
1 participant
Bumps alloy-provider from 1.8.3 to 2.0.5.
Release notes
Sourced from alloy-provider's releases.
... (truncated)
Changelog
Sourced from alloy-provider's changelog.
... (truncated)
Commits
653989fchore: release 2.0.5ee8c72fchore: release 2.0.5a90ea92chore: release 2.0.551090d3chore: release 2.0.52d3a3fbdocs(rpc-types-eth): correct sealed_header docs (#3995)a019321fix(ci): satisfy zepter secp256k1 propagation (#3993)a51afc1docs(node-bindings): clarify Reth genesis behavior (#3994)2aa6712chore(deps): bump github/codeql-action from 4.35.2 to 4.35.4 (#3990)f97b3cbfix(network): preserve transaction request extra fields51cb51dchore(deps): bump taiki-e/install-action from 2.75.27 to 2.77.1