chore(deps): bump alloy-contract from 1.8.3 to 2.0.5#1460
chore(deps): bump alloy-contract from 1.8.3 to 2.0.5#1460dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
dependencies
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved PR — 24ad367e
Blanket team auto-approval is enabled for this reviewer service.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: blanket_auto_approve · 2026-06-15T12:09:14Z
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 | 1 (1 strong-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 900.4s (2 bridge agents) |
| Total | 900.4s |
💰 Value — redundant-or-flawed
Bumps alloy-contract to 2.0 while leaving the rest of the alloy stack at 1.8, forcing Cargo to resolve two incompatible alloy versions and breaking type compatibility across the workspace.
- What it does: Changes Cargo.toml to bump alloy-contract from 1.8 to 2.0 while keeping alloy-provider, alloy-network, alloy-rpc-types-eth, alloy-signer, etc. at 1.8; Cargo.lock now contains both alloy-contract 1.8.3 and 2.0.5, plus alloy-provider 1.8.3 and 2.0.5.
- Goals it achieves: Pick up alloy-contract 2.0.5 bug fixes and improvements (e.g., deduplicated AnyRpcTransaction conversion helpers, cleaned-up failed impersonated sends, divide-by-zero fix in EIP-1559 base-fee calculation) without migrating the entire alloy stack.
- Assessment: Bad on its merits. alloy-contract is a high-level crate tightly coupled to alloy-provider/alloy-network types; the workspace uses those same crates directly at 1.8. Mixing major versions makes types from 1.8.3 and 2.0.5 distinct Rust types, so trait bounds and generic arguments (e.g., ContractInstance::<RootProvider, Ethereum>) will not match. This is the exact 'mix alloy 1.x/2.x types' problem th
- Better / existing approach: Either keep alloy-contract at 1.8, or perform the coordinated alloy-stack migration to 2.0 that was noted as needed in commit 8c58fa5 (which explicitly excluded alloy-rpc-types-eth 1.8→2.0 for the same reason). A coordinated migration would bump alloy, alloy-provider, alloy-network, alloy-contract, alloy-rpc-types, alloy-rpc-types-eth, alloy-signer, alloy-signer-local, alloy-consensus, alloy-trans
💰 Value Audit
🔴 Bump of alloy-contract to 2.0 mixes incompatible alloy 1.x/2.x types [against-grain] ``
Cargo.toml:424 now pins alloy-contract = '2.0' while Cargo.toml:419 still pins alloy-provider = '1.8'. The lockfile resolves both alloy-contract 1.8.3/2.0.5 and alloy-provider 1.8.3/2.0.5. Workspace code imports both crates together with generic trait bounds, e.g., crates/chain-setup/anvil/src/anvil.rs:3-5 uses alloy_contract::CallBuilder with alloy_provider::Provider and alloy_provider::network::Ethereum, and cli/src/tests/eigenlayer/deployment.rs:167 constructs alloy_contract::ContractInstance
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 | 2 (1 strong-concern, 1 medium-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 286.8s (2 bridge agents) |
| Total | 286.8s |
💰 Value — better-approach-exists
Bumps alloy-contract to 2.0.5 while leaving its tightly-coupled alloy-provider/alloy-network siblings at 1.8, which is a less coherent approach than a coordinated alloy 2.0 migration.
- What it does: Changes the workspace pin for alloy-contract from "1.8" to "2.0" (Cargo.toml:424) and updates Cargo.lock so that alloy-contract resolves to 2.0.5. Because alloy-contract 2.0.5 internally depends on alloy-provider 2.0.5 and alloy-network 2.0.5, the lockfile now contains both 1.8.3 and 2.0.5 versions of those crates, while the workspace still directly pins alloy-provider, alloy-network, and the allo
- Goals it achieves: Brings in upstream alloy 2.0 changes such as the AnyRpcTransaction helper deduplication, failed-impersonated-send cleanup, and divide-by-zero fix in base-fee calculation, and keeps the contract-call dependency current.
- Assessment: The goal is worthwhile, but the execution is incoherent for this crate. alloy-contract's public API is tightly coupled to alloy-provider and alloy-network types that the workspace uses directly: e.g.,
alloy_contract::ContractInstance::<RootProvider, alloy_network::Ethereum>in cli/src/tests/eigenlayer/deployment.rs:167 andalloy_contract::{CallBuilder, CallDecoder}plus `alloy_provider::{Provi - Better / existing approach: A coordinated workspace migration of the alloy 2.0 family: bump alloy-provider, alloy-network, alloy-consensus, alloy-transport, alloy-json-rpc, alloy-rpc-types-eth, and the alloy meta-crate to 2.0 alongside alloy-contract. This keeps the type system consistent, avoids duplicate crate versions in Cargo.lock, and matches the prior coordinated-bump precedent (git show 7061c5b). I checked Cargo.toml
🎯 Usefulness — redundant-or-flawed
Bumping only alloy-contract to 2.0 while the rest of the tightly-coupled alloy stack stays at 1.8 creates a version split that breaks compilation wherever contract and provider/network types meet.
- Integration: The workspace pins alloy-contract to 2.0 at Cargo.toml:424, but keeps alloy-provider, alloy-network, alloy-rpc-types-eth, and alloy-transport at 1.8 (Cargo.toml:417-427). Cargo.lock:250-269 shows alloy-contract 2.0.5 depends on alloy-network 2.0.5, alloy-provider 2.0.5, alloy-rpc-types-eth 2.0.5, and alloy-transport 2.0.5. Existing callers mix the two versions: crates/chain-setup/anvil/src/anvil.r
- Fit with existing patterns: It fights the codebase's alloy usage pattern. The workspace treats alloy as a version-locked family of crates (Cargo.toml:409-435) and passes provider/network types between alloy-contract, alloy-provider, and alloy-network throughout the code (e.g., crates/evm-extra/src/util.rs:25, crates/clients/eigenlayer/src/client.rs:42, examples/x402-blueprint/src/oracle/uniswap.rs:28). A single-crate bump wi
- Real-world viability: It will not hold up under any real use because the build fails at compile time wherever the split versions interact. The failure is not confined to an edge path; it hits core call sites such as contract instantiation and call building.
🎯 Usefulness Audit
🔴 alloy-contract 2.0 is wired to an incompatible 1.8 alloy-provider/network stack [integration] ``
Evidence: Cargo.toml:424 pins alloy-contract = "2.0" while Cargo.toml:419-423 keep alloy-provider, alloy-network, etc. at "1.8". Cargo.lock:250-269 proves alloy-contract 2.0.5 pulls in alloy-provider 2.0.5, alloy-network 2.0.5, alloy-rpc-types-eth 2.0.5, and alloy-transport 2.0.5. crates/chain-setup/anvil/src/anvil.rs:3-5 and cli/src/tests/eigenlayer/deployment.rs:167 pass 1.8 provider/network types into 2.0 contract types, which is a compile error in Rust. The correct fix is to bump the whole a
💰 Value Audit
🟠 Partial alloy-contract bump creates a version split with its coupled dependencies [better-architecture] ``
Evidence: Cargo.toml pins alloy-contract to 2.0 (line 424) but alloy-provider to 1.8 (line 419), alloy-network to 1.8 (line 423), and the alloy meta-crate to 1.8 (line 409). Cargo.lock now resolves alloy-contract 2.0.5, which depends on alloy-provider 2.0.5 and alloy-network 2.0.5, while workspace crates still receive alloy-provider 1.8.3 and alloy-network 1.8.3. Workspace code explicitly couples these types, e.g.,
ContractInstance::<RootProvider, alloy_network::Ethereum>at cli/src/tests/eige
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 | 2 (2 strong-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 878.0s (2 bridge agents) |
| Total | 878.0s |
💰 Value — redundant-or-flawed
Bumps workspace alloy-contract to 2.0 while leaving alloy-provider/network/consensus at 1.8, splitting the alloy type graph and breaking crates that pass 1.8 providers into 2.0 CallBuilders; should not ship as-is.
- What it does: Changes the workspace pin of alloy-contract from "1.8" to "2.0" (Cargo.toml:424) and updates Cargo.lock so workspace crates resolve to alloy-contract 2.0.5. It does not change any source files and leaves the rest of the alloy stack (provider, network, consensus, rpc-types-eth, transport, and the umbrella alloy crate) at 1.8.x.
- Goals it achieves: Pick up alloy-contract 2.0 fixes/perf improvements and stay current with upstream alloy releases.
- Assessment: This is a flawed change on its merits. alloy-contract's public API is tightly coupled to the provider/network stack version; bumping it alone pulls in a second copy of alloy-provider/alloy-network (2.0.5) while the workspace still uses 1.8.3. Code that couples the two versions directly — such as binding alloy_contract::CallBuilder<P,D,Ethereum> to alloy_provider::Provider (crates/chain-s
- Better / existing approach: Bump the alloy stack that alloy-contract depends on in lockstep — at minimum alloy-provider (Cargo.toml:419), alloy-network (Cargo.toml:423), alloy-consensus (Cargo.toml:425), alloy-rpc-types-eth (Cargo.toml:418), alloy-transport (Cargo.toml:427), and the umbrella alloy crate (Cargo.toml:409) — or keep alloy-contract pinned at 1.8 until the workspace can migrate wholesale. The codebase already has
🎯 Usefulness — redundant-or-flawed
Bumping only alloy-contract to 2.0 while the rest of the interacting alloy-* stack remains on 1.8 creates incompatible v1/v2 types in the same build graph and breaks compilation for the crates that actually use it.
- Integration: No. The new alloy-contract 2.0.5 is reachable only as a direct workspace dependency, but it is not wired correctly. Cargo.lock:258-261 shows alloy-contract 2.0.5 depends on alloy-network 2.0.5 and alloy-provider 2.0.5, yet Cargo.lock:3124-3125 shows blueprint-chain-setup-anvil depends on alloy-contract 2.0.5 and alloy-provider 1.8.3 at the same time. Running `cargo tree -p blueprint-chain-setup-an
- Fit with existing patterns: It fights the codebase's grain. The root Cargo.toml (lines 409-428) keeps the alloy umbrella and the core alloy-* family—provider, network, signer, transport, consensus—at 1.8, while a few outliers (eips, rpc-client, transport-http, signer-aws/gcp) were already moved to 2.0 as a group. A major-version bump of alloy-contract should be accompanied by alloy-provider, alloy-network, alloy-signer, allo
- Real-world viability: It will not survive a real build. Cargo.lock already contains both alloy-contract 1.8.3 (used by the alloy 1.8 umbrella, tnt-core-bindings at Cargo.lock:14429-14431, and eigensdk) and alloy-contract 2.0.5 (forced by this workspace dependency). Code that passes a v1 provider into a v2 contract call—e.g.,
blueprint-chain-setup-anvil::get_receiptand `eigenlayer-extra::get_allocation_manager_addres
💰 Value Audit
🔴 Partial alloy-contract 2.0 bump splits provider/network types with the rest of the workspace [against-grain] ``
Cargo.toml:424 pins alloy-contract to 2.0 while Cargo.toml:409/419/423 keep alloy, alloy-provider, and alloy-network at 1.8. Cargo.lock:249-261 shows alloy-contract 2.0.5 depends on alloy-provider 2.0.5/alloy-network 2.0.5, but Cargo.lock:3121-3125 shows blueprint-chain-setup-anvil still depends on alloy-contract 2.0.5 plus alloy-provider 1.8.3. Source code couples the two versions: crates/chain-setup/anvil/src/anvil.rs:3-5 imports alloy_contract::{CallBuilder,CallDecoder} and alloy_provider::{P
🎯 Usefulness Audit
🔴 Partial alloy-contract 2.0 bump creates a v1/v2 type mismatch [integration] ``
Evidence: Cargo.lock:258-261 shows alloy-contract 2.0.5 depends on alloy-network 2.0.5 and alloy-provider 2.0.5; Cargo.lock:3124-3125 shows blueprint-chain-setup-anvil depends on alloy-contract 2.0.5 and alloy-provider 1.8.3 simultaneously.
cargo tree -p blueprint-chain-setup-anvil -i alloy-contract@2.0.5confirms the 2.0.5 edge is only the direct dependency, andcargo tree -p blueprint-chain-setup-anvil -i alloy-provider@1.8.3confirms the crate also directly depends on provider 1.8.3. crat
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 | 1 (1 strong-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 900.3s (2 bridge agents) |
| Total | 900.3s |
🎯 Usefulness — redundant-or-flawed
Bumping alloy-contract to 2.0 while leaving alloy-provider/alloy-network/alloy-signer at 1.8 creates a non-compiling, cross-major-version type mismatch across every crate that consumes both.
- Integration: The change only touches Cargo.toml/Cargo.lock; no source code is updated. The workspace already wires alloy-contract through workspace = true, so crates like blueprint-client-tangle, blueprint-manager, blueprint-chain-setup-anvil, and blueprint-runner automatically pick up 2.0.5. However, Cargo.lock now contains two copies of the tightly-coupled alloy-provider/alloy-network/alloy-signer families (
- Fit with existing patterns: The codebase uses a workspace-managed, single-source-of-truth pattern for alloy versions in Cargo.toml:419-435. Partial bumps are already present (alloy-eips 2.0, alloy-transport-http 2.0, alloy-signer-aws/gcp 2.0), but alloy-contract is uniquely coupled to alloy-provider and alloy-network: the generated Instance types carry the provider/network generics. Bumping only alloy-contract therefore figh
- Real-world viability: It will not survive even the happy path — the crate graph cannot type-check. For example, crates/clients/tangle/src/client.rs:12 imports DynProvider/ProviderBuilder from alloy_provider (1.8), defines TangleProvider = DynProvider at line 135, and at lines 531-546 passes Arc to ITangleInstance::new, IMultiAssetDelegation::new, and IOperatorStatusRegistryInstance::new genera
🎯 Usefulness Audit
🔴 alloy-contract 2.0 is wired to crates still on alloy-provider 1.8, producing incompatible types [integration] ``
Cargo.toml:424 sets alloy-contract = "2.0" while Cargo.toml:419 keeps alloy-provider = "1.8" and Cargo.toml:423 keeps alloy-network = "1.8". Cargo.lock confirms the split: it contains both alloy-contract 2.0.5 and alloy-contract 1.8.3, and both alloy-provider 2.0.5 (pulled in by alloy-contract 2.0.5) and alloy-provider 1.8.3 (used directly by workspace crates). blueprint-client-tangle/Cargo.toml:29-33 depends on both from the workspace, and client.rs:531-546 passes an alloy-provider 1.8 DynProvi
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 — audit-incomplete
| Verdict | audit-incomplete |
| Concerns | 0 (none) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 1861.6s (2 bridge agents) |
| Total | 1861.6s |
💰 Value — error
value agent produced no parseable value-audit JSON.
- Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge error: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content; opencode/zai-coding-plan/glm-5.2: bridge stream ended without value-audit content; opencode/deepseek/deepseek-v4-pro: bridge stream ended without value-audit content
🎯 Usefulness — error
usefulness agent produced no parseable value-audit JSON.
- Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge error: opencode/zai-coding-plan/glm-5.2: bridge stream ended without value-audit content; opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content; opencode/deepseek/deepseek-v4-pro: bridge stream ended without value-audit content
No PR concerns were produced because the value/usefulness agent pass did not complete. Treat this audit as incomplete, not as approval.
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.
❌ 2 Blocking Findings — 24ad367e
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-22T16:07:12Z · immutable trace
dependabot
Bot
force-pushed
the
dependabot/cargo/alloy-contract-2.0.5
branch
from
24ad367 to
ba990e5
Compare
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Refreshed approval after new commits — ba990e5a
A previous trusted approval on this PR was invalidated by new commits.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: stale_approval_refresh · 2026-07-03T01:02:44Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Concerns | 1 (1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 900.1s (2 bridge agents) |
| Total | 900.1s |
💰 Value — sound-with-nits
Routine dependabot step in an ongoing piecemeal alloy 1.8→2.x migration; sound and in-grain, with one source-level provider-version coupling worth eyeballing.
- What it does: Bumps the workspace alloy-contract dependency from 1.8 to 2.0 (Cargo.toml:425); Cargo.lock resolves it to alloy-contract 2.1.0 and refreshes the already-2.x alloy substack (consensus/eips/network/provider/signer/transport/rpc-client etc.) from 2.0.5 to 2.1.0, while the legacy 1.8.3 copies remain for external consumers.
- Goals it achieves: Advance the alloy 1.8→2.x migration (already in flight for rpc-client/eips/transport-http/signers), staying current with upstream alloy 2.x fixes (e.g. the eip1559 divide-by-zero guard, impersonated-send cleanup noted in the release notes) and unblocking the eventual full-stack move.
- Assessment: A coherent incremental step in an established, in-grain migration: prior PRs (#1428, #1404) bumped sibling alloy crates individually, so piecemeal is this repo's chosen path. The duplicated alloy copies in the lockfile (alloy-contract 1.8.3+2.1.0, alloy-provider 1.8.3+2.1.0) are largely forced by external deps (eigensdk/others still pin alloy 1.8) rather than introduced carelessly — a coordinated
- Better / existing approach: No materially better single-PR approach: dependabot can only touch one crate at a time, and the 1.8/2.x coexistence is forced by external deps. The only real friction point is at crates/chain-setup/anvil/src/anvil.rs:4 and :223-226, where alloy-contract 2.1.0's CallBuilder meets the alloy_provider::Provider trait imported from the still-1.8.3 workspace alloy-provider — a spot where the two major v
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content
🎯 Usefulness — error
usefulness agent produced no parseable value-audit JSON.
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
- Bridge error: no parseable JSON response
💰 Value Audit
🟡 alloy-contract moves to 2.x ahead of its provider/network siblings [maintenance] ``
Cargo.toml:425 bumps alloy-contract to 2.0 while alloy-provider (1.8, line 420), alloy-network (1.8, line 424), alloy-consensus (1.8, line 426) and the umbrella alloy crate (1.8, line 410) stay put. Because alloy-contract 2.1.0 depends on alloy-provider/network 2.x, the lockfile now carries alloy-provider as two copies (1.8.3 + newly-added 2.1.0). This is forced by external deps so not strictly avoidable, but it leaves one source-level coupling — crates/chain-setup/anvil/src/anvil.rs:4 imports a
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.
|
| State | Detail |
|---|---|
| Interrupted | max run seconds |
No review verdict was produced for this run. Trigger a fresh review on the current PR head if the PR is still open.
tangletools · #1460 · model: kimi-for-coding · updated 2026-07-03T03:04:22Z
Bumps [alloy-contract](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-contract dependency-version: 2.0.5 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-contract-2.0.5
branch
from
ba990e5 to
5acf16c
Compare
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Concerns | 1 (1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 900.2s (2 bridge agents) |
| Total | 900.2s |
💰 Value — sound-with-nits
Bumps the alloy-contract workspace dep from the 1.8 line to the 2.x line (incremental step in the repo's ongoing alloy migration); coherent and API-compatible, with a stale title and incidental cluster bump worth noting.
- What it does: Changes one line in the root Cargo.toml workspace.dependencies: alloy-contract = "1.8" → "2.0" (Cargo.toml:425), plus the regenerated Cargo.lock. Because the spec "2.0" resolves to the newest 2.x, the lock does NOT pin 2.0.5 (as the PR title claims) but pulls alloy-contract 2.1.0, alloy-provider 2.1.0, alloy-network 2.1.0, and bumps the pre-existing 2.0.5 cluster (alloy-consensus/eips/rpc-client/t
- Goals it achieves: Continue the gradual alloy 1.8 → 2.x migration the workspace is mid-flight on. The [workspace.dependencies] block (Cargo.toml:409-436) is already a deliberate mix: alloy/alloy-rpc-types/alloy-provider/alloy-network/alloy-signer/alloy-consensus on "1.8" while alloy-eips/alloy-rpc-client/alloy-transport-http/alloy-signer-aws/alloy-signer-gcp are on "2.0". Bringing alloy-contract into the 2.x line mo
- Assessment: Coherent and in the grain of the codebase. It extends the established partial-migration pattern (Cargo.toml:425-429 already pair alloy-contract=2.0 with alloy-eips=2.0/transport-http=2.0), requires zero source edits so the API surface is compatible for the migrated crates, and the dual-version coexistence (alloy-contract 1.8.3 + 2.1.0, alloy-provider 1.8.3 + 2.1.0) is the expected, already-substan
- Better / existing approach: none for the scoped goal — the only materially 'better' design is a big-bang migration that bumps ALL alloy deps (including alloy-provider/alloy-network/alloy-signer/alloy-consensus still on "1.8") to 2.x at once and deletes the 1.8.3 duplicates, collapsing the dual-version compile cost. But that is a large breaking change requiring source edits across every crate and is explicitly out of scope fo
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content
🎯 Usefulness — error
usefulness agent produced no parseable value-audit JSON.
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
- Bridge error: no parseable JSON response
💰 Value Audit
🟡 PR title understates scope: pulls 2.1.0 and bumps the whole 2.x cluster, not alloy-contract 2.0.5 [maintenance] ``
The dependabot-generated title says '1.8.3 to 2.0.5' but the actual Cargo.lock (lines 250-261) resolves alloy-contract to 2.1.0 and re-resolves every already-2.0.x alloy crate from 2.0.5 → 2.1.0 (consensus/eips/rpc-client/transport/transport-http/serde/signer/json-rpc/rpc-types-eth/network-primitives/consensus-any/rpc-types-any/tx-macros). This is normal Cargo semver behavior for
version = "2.0"(>=2.0.0,<3.0.0), not a defect, but a reviewer should be aware the PR is a wider within-major refre
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 —
|
| glm | deepseek | aggregate | |
|---|---|---|---|
| Readiness | 61 | 0 | 0 |
| Confidence | 70 | 70 | 70 |
| Correctness | 61 | 0 | 0 |
| Security | 61 | 0 | 0 |
| Testing | 61 | 0 | 0 |
| Architecture | 61 | 0 | 0 |
Reviewer score is advisory once the run is complete and the verdict has no blockers.
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.
Blocking
🔴 HIGH Isolated alloy-contract bump without bumping paired alloy crates — Cargo.toml
alloy-contract bumped to 2.0 while alloy-provider (424), alloy-network (424), alloy-transport (428), alloy-consensus (426), alloy-json-rpc (413), alloy-signer (422), alloy-pubsub (421), and alloy-rpc-types (418) remain at 1.8. alloy-contract 2.x transitively depends on all of these at 2.x. The bump should coordinate all alloy crates that alloy-contract depends on, or explicitly hold alloy-contract back at 1.8 if those crates cannot be bumped. Current state: alloy-rpc-client (417), alloy-eips (427), alloy-transport-http (429), alloy-signer-aws (434), and alloy-signer-gcp (435) are already at 2.0, so a coordinated alloy-2.0 migration exists — but alloy-provider, alloy-network, alloy-transport, and alloy-consensus were left behind.
🔴 HIGH alloy-contract bumped to 2.0 alone breaks the build (CallBuilder 2.0 vs Ethereum/Provider 1.8 type mismatch) — Cargo.toml
Cargo.toml:425 sets alloy-contract="2.0" while the
alloyumbrella stays at "1.8" (Cargo.toml:410) and alloy-provider/alloy-network/alloy-rpc-types-eth stay at "1.8" (Cargo.toml:418-420). The head lockfile confirms two disjoint copies: alloy-contract 1.8.3 (pulled by thealloy1.8 umbrella) AND alloy-contract 2.1.0 (the new direct dep), and alloy-contract 2.1.0 depends on alloy-provider 2.1.0 / alloy-network 2.1.0 which also duplicate. Concrete break site: crates/chain-setup/anvil/src/anvil.rs:3use alloy_contract::{CallBuilder,CallDecoder};(2.0) combined with anvil.rs:4-5use alloy_provider::Provider; use alloy_provider::network::Ethereum;(1.8, since alloy_provider resolves to the direct 1.8.3 dep) and anvil.rs:223call: CallBuilder<P,D,Ethereum>. The 1.8Ethereumimplements
Other
🟠 MEDIUM Resolved version (2.1.0) exceeds stated intent (2.0.5) — Cargo.toml
Commit message says 'bump alloy-contract from 1.8.3 to 2.0.5' but Cargo.lock resolves to 2.1.0. While both satisfy the 2.0 constraint, the auto-resolution picked a later semver-minor release than the author intended. If 2.0.5 was specifically tested, the resolved 2.1.0 is untested. Not a correctness bug but a process gap.
🟡 LOW Two parallel alloy core stacks (1.8.3 + 2.1.0) coexist; several crates mix alloy-contract 2.1.0 with alloy-provider 1.8.3 — Cargo.lock
Concrete evidence in this lock: blueprint-chain-setup-anvil's dependency list now reads 'alloy-contract 2.1.0' (which transitively pulls alloy-network 2.1.0 + alloy-provider 2.1.0) alongside a direct 'alloy-provider 1.8.3' + 'alloy-network 1.8.3'. The same 2.1.0/1.8.3 split recurs in ~10 workspace crates. Impact: the lock now compiles two full copies of the alloy core, inflating build time and binary size, and any source path that hands a 1.8.3 Provider/Network into a 2.1.0 contract CallBuilder will hit a type-mismatch (different trait versions). This is the observable signature of a half-finished migration. The lock is NOT wrong -- it faithfully resolves what the Cargo.toml files requested -- but the global verifier should confirm the other shot's Cargo.toml/source actually compiles and t
🟡 LOW tracing-loki silently shifted reqwest 0.11.27 -> 0.12.28 under resolver pressure — Cargo.lock
Evidence: tracing-loki 0.2.6 entry (checksum ba3beec9..., unchanged) switched its reqwest edge from '0.11.27' to '0.12.28'. Verified via crates.io API that tracing-loki 0.2.6 declares reqwest '>=0.11.10, <0.13.0' default-features=false, so this is a legal resolution and the crate code is byte-identical; reqwest 0.12.28 was already present in the tree. Benign -- telemetry-only sink, minimal HTTP surface used. Noting only so the global verifier is aware reqwest 0.11.27 is now retained solely by legacy consumers; if nothing else needs 0.11.x it could be dropped in a follow-up to slim the dep tree.
🟡 LOW Bump leaves the workspace in a half-migrated alloy 1.8/2.0 state with duplicated crates — Cargo.toml
Same root cause, distinct consequence: after this bump the lockfile carries both major versions for essentially the entire alloy stack (contract/network/provider/rpc-types-eth/rpc-client/eips/transport/signer/serde/json-rpc/transport-http/transport-ws each at 1.8.3 AND 2.x). In-tree the split is already visible: crates/sdk/src/error.rs:52 uses
alloy::contract::Error(1.8 via umbrella) while crates/runner, crates/eigenlayer-extra, crates/clients/eigenlayer, crates/chain-setup/anvil usealloy_contract::Error/alloy_contract::{CallBuilder,...}(2.0 direct). Even where it compiles, the duplication inflates compile time and binary size and any future code that crosses the 1.8<->2.0 boundary silently breaks. Recommend a single coordinated alloy-2.0 migration rather than per-crate Dependabot
tangletools · 2026-07-03T04:11:40Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 2 Blocking Findings — 5acf16c8
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-07-03T04:11:40Z · immutable trace
1 participant
Bumps alloy-contract from 1.8.3 to 2.0.5.
Release notes
Sourced from alloy-contract's releases.
... (truncated)
Changelog
Sourced from alloy-contract'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