bug: InvalidBlockRange::EmptyRange can never be produced

[haileymarshall]

Packages versions

miden-node: 0.16.0-rc.3 (the code is in crates/proto/src/domain/block.rs, so this is miden-node-proto)

Bug description

BlockRange::into_inclusive_range checks two conditions. It first returns StartGreaterThanEnd when start > end, and then returns EmptyRange when block_range.is_empty().

For a freshly constructed RangeInclusive, is_empty() is true exactly when start > end — which the first check has already rejected. So the second branch can never run, and since that is the only place EmptyRange is constructed anywhere in the repo, that variant of the public InvalidBlockRange error can never be produced.

The effect is that the error type advertises a failure mode that callers may write handling for, but which cannot occur. It also reads as though empty ranges were a separate case being guarded against, when there is no such case: an inclusive range with start == end covers exactly one block and is valid.

I have a fix ready that removes the unreachable branch and the variant, together with tests covering the boundaries — inverted ranges rejected, start == end accepted as a single-block range, ascending ranges accepted. Happy to open a PR if someone assigns this to me.

One note: removing the variant is a breaking change to miden-node-proto's public error type, although nothing in the repo matches on it. If you would rather keep the variant and only drop the dead branch, that is an easy change to make.

How can this be reproduced?

1. Read into_inclusive_range in crates/proto/src/domain/block.rs.
2. RangeInclusive::new(a, b).is_empty() is true exactly when a > b, and the preceding check already returns StartGreaterThanEnd for that case, so the is_empty() branch is unreachable.
3. grep -rn "EmptyRange" --include=*.rs . returns only the variant declaration and that single unreachable construction site.

Relevant log output

[Kewe63]

Hi, I’d like to work on this issue. I’ve looked into crates/proto/src/domain/block.rs, and the root cause seems to be that BlockRange::into_inclusive_range checks start > end first and returns InvalidBlockRange::StartGreaterThanEnd, while RangeInclusive::is_empty() would only be true for the same inverted-range case.

That makes the later EmptyRange branch unreachable, and InvalidBlockRange::EmptyRange is not constructed anywhere else in the repo. My proposed fix is to remove the unreachable branch and the unused EmptyRange variant, then add boundary tests covering:

• start > end is rejected with StartGreaterThanEnd
• start == end is accepted as a valid single-block inclusive range
• start < end is accepted as a normal ascending range

I understand that removing the enum variant is technically a breaking API cleanup for miden-node-proto. If maintainers prefer a non-breaking version, I can instead keep the variant and only remove the unreachable branch.

Could you please assign this issue to me?

[kutluhaneth46]

Taking this — I'll remove the unreachable EmptyRange branch (and the dead variant if maintainers prefer the breaking cleanup), with boundary tests for start>end / start==end / start<end.