chore(deps): bump alloy-json-rpc from 1.8.3 to 2.0.5#1459
chore(deps): bump alloy-json-rpc from 1.8.3 to 2.0.5#1459dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [alloy-json-rpc](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-json-rpc 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
added
dependencies
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved PR — 849e416f
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:08:26Z
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 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 338.0s (2 bridge agents) |
| Total | 338.0s |
💰 Value — sound-with-nits
Bumps the workspace direct dep alloy-json-rpc from 1.8 to 2.0, aligning it with alloy-rpc-client, alloy-eips, and alloy-transport-http which are already on 2.x in the workspace; a coherent incremental follow-up to the team's established partial-alloy-upgrade pattern.
- What it does: Changes Cargo.toml:412 to require alloy-json-rpc 2.0 instead of 1.8, which resolves blueprint-client-evm to alloy-json-rpc 2.0.5 in Cargo.lock:3124. The only workspace crate that consumes the workspace alloy-json-rpc alias is crates/clients/evm, whose instrumented_client.rs directly imports RpcRecv/RpcSend/RpcError at lines 5 and 50.
- Goals it achieves: Keeps the JSON-RPC layer current and consistent with the 2.x alloy crates already declared in the workspace (alloy-rpc-client 2.0 at Cargo.toml:416, alloy-eips 2.0 at Cargo.toml:426, alloy-transport-http 2.0 at Cargo.toml:428). It also follows the precedent set by commit 7061c5b (git log -- Cargo.toml), which bumped those three crates to 2.0 while leaving alloy-json-rpc at 1.8 and reported 'no API
- Assessment: Good on its merits. The change is minimal and targeted, touching only the workspace alias and the resulting lockfile entry for the single direct consumer. No source-code changes are included, consistent with the prior partial bump (7061c5b) that reported no broken workspace API surface, indicating the used traits/error types are stable enough for this bump.
- Better / existing approach: A coordinated bump of every alloy crate to 2.x would leave the workspace in a cleaner, single-version state. However, the codebase already practices incremental alloy upgrades (7061c5b upgraded alloy-rpc-client/alloy-eips/alloy-transport-http to 2.0 while leaving alloy-json-rpc and most other alloy crates at 1.8), and no existing automation or reusable component manages alloy versions. Within that
🎯 Usefulness — redundant-or-flawed
Bumping alloy-json-rpc to 2.0 while alloy-provider/alloy-network/alloy-transport remain at 1.8 introduces a major-version type mismatch in blueprint-client-evm that breaks compilation.
- Integration: Does not wire correctly. blueprint-client-evm imports RpcSend/RpcRecv/RpcError from alloy-json-rpc 2.0 (Cargo.toml:412, crates/clients/evm/Cargo.toml:31, crates/clients/evm/src/instrumented_client.rs:5,50), but its Provider impl calls alloy-provider 1.8's raw_request, which expects RpcSend/RpcRecv from alloy-json-rpc 1.8. Cargo.lock now contains both alloy-json-rpc 1.8.3 (used by alloy-provider 1.
- Fit with existing patterns: Fights the codebase's grain. The workspace pins the alloy ecosystem to a common major line: alloy-provider 1.8, alloy-network 1.8, alloy-transport 1.8, alloy-consensus 1.8, etc. (Cargo.toml:409-428). Bumping one foundational type crate without its dependents is inconsistent with that pattern and forces duplicate major versions of the same crate into the dependency graph.
- Real-world viability: Will not hold up; the crate will not compile. Even if it compiled, carrying two major versions of alloy-json-rpc in the same crate is a maintenance hazard: error conversions, trait impls, and downstream type expectations will diverge at runtime use sites.
🎯 Usefulness Audit
🔴 Major-version mismatch breaks blueprint-client-evm compilation [integration] ``
blueprint-client-evm is the only direct consumer of alloy-json-rpc (crates/clients/evm/Cargo.toml:31). It uses RpcSend/RpcRecv (instrumented_client.rs:5,809-816) with Provider::raw_request from alloy-provider 1.8, but the workspace now resolves alloy-json-rpc to 2.0 (Cargo.toml:412). Cargo.lock shows alloy-provider 1.8.3 depends on alloy-json-rpc 1.8.3 (Cargo.lock:548), while blueprint-client-evm depends on alloy-json-rpc 2.0.5 (Cargo.lock:3124). Because Rust treats different major versions as d
💰 Value Audit
🟡 Workspace still carries a split alloy ecosystem [maintenance] ``
Cargo.toml:409-428 shows most alloy crates (alloy, alloy-provider, alloy-network, alloy-consensus, etc.) remain at 1.8 while alloy-json-rpc, alloy-rpc-client, alloy-eips, and alloy-transport-http are at 2.0. As a result, Cargo.lock still contains both alloy-json-rpc 1.8.3 and 2.0.5. This is acceptable given the precedent in commit 7061c5b, but future maintenance should aim for a coordinated alloy 2.x migration to eliminate the dual-version lockfile.
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 — 849e416f
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-15T12:18:52Z · immutable trace
|
Closing: alloy 1.x -> 2.0 is a breaking major-version migration, not a safe auto-bump. The workspace pins alloy 1.8 and consumes tnt-core-bindings 0.19 which is built against alloy 1.0 — moving one alloy crate to 2.0 breaks the version-unified workspace and the blueprint-manager's getLogs/ABI-decode paths (the tnt-core 0.19 upgrade + live Tempo operators). alloy 2.0 needs a coordinated migration (tnt-core-bindings regenerated on alloy 2 first, then the whole workspace) — tracked separately, not via Dependabot. |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
2 participants
Bumps alloy-json-rpc from 1.8.3 to 2.0.5.
Release notes
Sourced from alloy-json-rpc's releases.
... (truncated)
Changelog
Sourced from alloy-json-rpc'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.1Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)