Require an approved result before a non-awaitingReview application state decodes
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
Research direction
Start in crates/registry-breg-client/src/lifecycle.rs at decode_external_review_status around line 2244, then inspect decode_external_review_application around line 2396 and the existing applicationId/state checks. Add decoder unit tests for rejected, cancelled, and pending results paired with each non-awaitingReview application state. Done means these malformed payloads are rejected while approved results continue to decode correctly.
Written by the indexing model from the issue text.
Description
An automated review of #1189 flagged a missing cross-field invariant in the BReg external review status decoder. decode_external_review_application in crates/registry-breg-client/src/lifecycle.rs (around line 2396) decodes application.state (ready, queued, applying, applied, blocked, in addition to awaitingReview) independently of result.state; the caller, decode_external_review_status (around line 2244), only cross-checks that application.applicationId is present exactly when application.state == Applied, and never checks result.state against application.state.
Failure scenario: a malformed or corrupted status payload that pairs a rejected, cancelled, or even still-pending result with an application state of ready/queued/applying/applied/blocked decodes successfully, even though only an approved result should ever authorize moving an application out of awaitingReview. Any downstream code that trusts a decoded non-awaitingReview application state as proof of approval would be acting on an unapproved or rejected change.
Suggested fix:
- In
decode_external_review_status, requireresult.state == Approvedwheneverapplication.state != AwaitingReview, and reject the payload otherwise. - Add decoder unit tests covering a
rejected/cancelled/pendingresult paired with each non-awaitingReviewapplication state.
Filed from the review of #1189; not merge-blocking.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 3h 45m
- Merged PRs (30d)
- 134
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1239 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
registrystack/registry-stack#1235 ·
-
area:breg bug good first issue rust
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1227 ·
-
area:casework documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1217 ·
-
area:breg documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
registrystack/registry-stack#1213 ·
All issues in registrystack/registry-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100