A zero commit count is guarded in one place and decremented unchecked in three
- Dominant language
- Rust
- Stars
- 3
- Forks
- 0
- Avg merge
- 1d 42m
- Merged PRs (30d)
- 11
Description
Two parts of the server disagree about whether a principal's commit count can be zero, and only one of them can be right.
The witness sync path treats zero as a real, reachable case: it guards against it explicitly before using the count. Three sites in the route layer subtract one from the same count with no check, on an unsigned integer.
So either the guard is unreachable and therefore dead, or those three subtractions underflow — wrapping to the maximum unsigned value in release builds and panicking in debug ones. Both cannot hold.
## Why it is worth resolving rather than leaving
The two possibilities have opposite fixes, and the cheap-looking response to each is wrong:
If zero is genuinely unreachable, the guard should be removed or replaced with an assertion that says so — a defensive check on an impossible state is not free, because a future reader treats it as evidence the state occurs and reasons accordingly. That is how the disagreement arose.
If zero is reachable, three sites compute an enormous index from it and whatever they do next is wrong. Wrapping is worse than panicking here, because a panic is visible and a wrapped index is a lookup that silently misses or a bound that silently passes.
Neither branch is expensive. What is expensive is leaving a contradiction in place where a reader can pick either side and be plausibly justified.
## What resolving this involves
Establish whether a principal can hold an indexed commit count of zero. That is a question about the storage engine's states, not about the route layer — a genesis principal, a reindexed principal, and a principal whose commits were all rejected are the cases to check, and the first two have already been sources of surprise elsewhere in this component.
Then make both places agree. If zero is reachable, use a checked subtraction and decide what each site should do when it fires. If it is not, delete the guard and record why.
This was found while reviewing an unrelated change to the sync path, which surfaced the guard; the route-layer sites are pre-existing and not caused by that work.
Related: #141.
Contributor guide
No contributing guide indexed for this repository
Research direction
Trace the witness sync path and the three route-layer subtraction sites, then inspect the storage engine states for genesis, reindexed, and all-rejected principals. Use related issue #141 and the existing zero-count guard to establish whether zero is reachable. Done means the storage behavior is established and every affected site consistently handles or rules out zero.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100