bug: arc-consensus-types `arbitrary` feature does not build standalone

[mehmetkr-31]

Summary

The arbitrary feature of arc-consensus-types does not build when the crate is compiled on its own.

Reproduction

On main:

$ cargo check -p arc-consensus-types --features arbitrary
error[E0433]: failed to resolve: could not find `Arbitrary` in `arbitrary`
  --> crates/types/src/address.rs:39:53
   |
39 | #[cfg_attr(feature = "arbitrary", derive(arbitrary::Arbitrary))]
   |                                                     ^^^^^^^^^ could not find `Arbitrary` in `arbitrary`

Adding only the derive feature moves the failure one step further:

error[E0277]: the trait bound `alloy_primitives::Address: Arbitrary<'_>` is not satisfied

Cause

The feature gates derive(arbitrary::Arbitrary) on Address but declares neither of the two things that derive needs:

1. arbitrary/derive — the derive macro lives behind that feature of the arbitrary crate.
2. alloy-primitives/arbitrary — the wrapped alloy_primitives::Address has no Arbitrary impl without it, so the generated impl does not satisfy its bound.

Why CI does not catch it

arc-consensus-db and arc-node-consensus both depend on alloy-rpc-types-engine with features = ["arbitrary"]. In a workspace build, feature unification turns on exactly what this crate omitted, so cargo clippy --all-targets --all-features at the workspace level passes and the gap stays invisible. It only appears when the crate is built alone — which is how a consumer would build it, and crates/types inherits publish from the workspace rather than opting out.

Suggested fix

Declare both, following the pattern arc-evm and arc-node already use, where the arbitrary feature forwards to its alloy dependencies explicitly:

[features]
arbitrary = ["dep:arbitrary", "alloy-primitives/arbitrary"]

[dependencies]
arbitrary = { workspace = true, optional = true, features = ["derive"] }

I have this working locally with no Cargo.lock change and no workspace regression, and opened #231 with it — happy to close that if you would rather take a different approach, such as enabling derive on the workspace-level arbitrary dependency instead.

[osr21]

Confirmed the reproduction and both root causes while reviewing the fix — PR #231 resolves this and I've approved it there (the two-line change is correct, follows the arc-evm/arc-node forwarding convention, and the standalone cargo check -p verification is valid precisely because resolver v2 doesn't unify features across unselected workspace members). Adding three findings from a repo scan that belong on the issue record:

1. Current blast radius is exactly one derive site. crates/types/src/address.rs is the only #[cfg_attr(feature = "arbitrary", derive(...))] in the repo, so this crate's declaration gap is the whole bug today — no other crate is latently broken the same way right now.

2. But the masking dependency is closer than the issue states. Beyond the alloy-rpc-types-engine unification path described here, arc-consensus-db directly depends on arc-consensus-types with features = ["arbitrary"] (as a dev-dependency for its test/fuzz harness). That means every workspace test run has been exercising the broken feature successfully — the feature isn't dormant, it's load-bearing for consensus-db's tests and has been working only via other crates' feature flags. That's worth knowing because it rules out the "just delete the under-used feature" alternative resolution: the feature has real consumers.

3. The class-level guard deserves its own issue. This bug pattern — optional feature only ever compiled under workspace-wide unification — will recur with the next cfg_attr derive added anywhere. cargo hack check --each-feature --workspace is the standard CI answer and would have caught this on the commit that introduced it; it also catches the inverse class (features that only build because of a default feature). Given crates/types inherits publish from the workspace, standalone-buildability of every feature is a publishing correctness requirement, not just hygiene. If maintainers agree, that's a small separate ci: issue rather than scope creep on #231 — happy to file it with the proposed job configuration if useful.

With #231 merged this can close; the cargo-hack guard is the only piece that would remain open.

[mehmetkr-31]

Ran the proposed guard against the workspace to put numbers behind point 3. It works, and it surfaces one blocker worth knowing before the job gets written.

The proposal is right, including the part I initially doubted. My first instinct was that workspace scope would unify features and mask exactly these bugs. That is true of plain cargo — but not of cargo-hack, which decomposes into per-package runs (cargo check --manifest-path crates/types/Cargo.toml --all-features), so --workspace keeps each crate isolated. Correcting that here since it is the crux of why the job works at all.

It catches both directions. cargo hack check --each-feature -p arc-consensus-types runs 5 configurations on main; 3 fail:

Configuration	Result
--all-features	E0433 → #233
--no-default-features	4× E0432 → #236
--no-default-features --features arbitrary	both at once
--no-default-features --features default	ok
--no-default-features --features signer-local	ok

And it is the only thing that would. The two commands CI runs today both report zero errors on main:

$ cargo check --workspace --all-features        # 0 errors  (masks #233)
$ cargo check --workspace --no-default-features # 0 errors  (masks #236)

So this is not a missing flag on the existing job — adding --no-default-features to a workspace-scoped check would catch nothing. The per-package decomposition is the whole mechanism.

The blocker: arc-signer fails by design. Full run is 64 configurations, and 4 fail — the three above plus:

cargo check --no-default-features on arc-signer (10/64)
error: At least one signing provider feature must be enabled

That is the deliberate compile_error! guard, and it is correct code — I cited it on #236 as the right way to express a genuine either/or. But cargo-hack counts it as a failure, so cargo hack check --each-feature --workspace stays red even after #231 and #237 land. The job needs one of: --exclude arc-signer, required-features on the crate, or --features local pinned for it. Worth settling in the job config rather than discovering it in the first CI run.

Cost. 64 configurations took ~69 minutes here (cold cache, local machine — CI with a warm cache will differ, but the shape holds). Only 8 of the 25 crates declare features at all, so scoping to those is worth considering if the full matrix is too slow for every PR; arc-node-execution (6 features) and arc-signer (5) dominate the count.

One correction to point 2 for the record: the arbitrary feature has two in-workspace consumers, not one — arc-consensus-db and arc-node-consensus both dev-depend on arc-consensus-types with features = ["arbitrary"]. Strengthens the argument that the feature has real users and should not simply be deleted.

Happy to write the workflow PR with the arc-signer handling and a scoping decision baked in if you file the ci: issue — your proposal, and you offered first, so I would rather not open a duplicate ahead of you.

[osr21]

Filed: #240, with your matrix results and the arc-signer constraint baked into the proposed job config — the workflow PR is yours as agreed.

Your correction to my point 2 is verified and accepted: arc-node-consensus also dev-depends on arc-consensus-types with features = ["arbitrary"], so two consumers, not one. Worth recording why my scan missed it, since it's the same trap the next repo audit will hit: the crate is named arc-node-consensus but lives in crates/malachite-app/ — I had grepped consumer manifests by directory paths matching crate names, and this is the one crate in the workspace where they diverge. Your count strengthens the resolution #237 took, too: with two test harnesses exercising arbitrary, both "delete the feature" non-options are now off the table for good reasons rather than assumed ones.

Two notes on the job config in #240, where I diverged slightly from a bare --exclude:

1. Rather than exempting arc-signer wholesale, I proposed a second invocation with --at-least-one-of local,remote — the crate has 5 features and the compile_error! guard only forbids the empty provider set, so full exclusion would trade one blind spot for another (e.g. integration alone, or local without remote, would go unchecked — the exact per-crate gap this job exists to close).
2. On cost: your 69-minute cold number is in the issue verbatim, with the suggestion to measure one warm-cache CI run before deciding between per-PR, merge-queue, or scoping to the 8 feature-declaring crates. Cheap to measure, and it keeps the scoping decision empirical.

The acceptance criterion writes itself, which is the satisfying part: the job must be red on main today and green once #231 and #237 land — the two bugs that motivated it double as its regression fixture.