Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Review client classifies a refused connection as an unknown outcome

Open Beginner friendly
  • Is something wrong?
#1,934 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
85/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
api, backend

Research direction

Start with ReviewClientError::mutation_class in crates/registry-review-client/src/error.rs and compare it to CaseworkClientError::is_outcome_unknown / mutation_class in crates/registry-casework-client/src/error.rs. Make Transport { kind: TransportKind::Connect } classify as Deterministic while timeouts and broken exchanges stay Ambiguous, then add a boundary test in crates/registry-review-client/tests/http_boundary.rs that refuses the connection and asserts the class. Done when that test passes and the doc comment on ReviewMutationErrorClass states the refused-connection rule.

Written by the indexing model from the issue text.

Description

area:casework bug criticality:p3 rust

Problem

registry-review-client and the Casework client disagree about a refused connection.

  • ReviewClientError::mutation_class (crates/registry-review-client/src/error.rs) returns Ambiguous for every Transport error, including TransportKind::Connect.
  • CaseworkClientError::is_outcome_unknown and mutation_class (crates/registry-casework-client/src/error.rs) return Deterministic for TransportKind::Connect, because a connection that was never established cannot have carried the request. The BReg, Messaging and Scheduling clients' is_outcome_unknown make the same call, and that predicate is what the shared keyed-mutation retry in registry-platform-httputil consults.

ReviewMutationErrorClass is re-exported from registry-stack-client, so a caller using the review client directly is told that a refused connection may have committed. The recovery that follows (resend under the same key) is safe, so this is an inconsistency rather than a correctness bug, but the two clients now document different meanings for the same class.

Found while reviewing #1933, which deliberately left create_or_recover_review_request and cancel_review_request outside the automatic resend (one exchange each).

Proposal

Make ReviewClientError::mutation_class return Deterministic for Transport { kind: TransportKind::Connect }, keep Ambiguous for timeouts and broken exchanges, and add a boundary test beside the existing ones in crates/registry-review-client/tests/http_boundary.rs that refuses the connection and asserts the class.

Done when

  • A refused connection classifies the same way in the review client as in the BReg, Casework, Messaging and Scheduling clients.
  • The review client's documentation of ReviewMutationErrorClass states that rule.
Dominant language
Rust
Stars
2
Forks
0
Avg merge
9h 14m
Merged PRs (30d)
241

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from registrystack/registry-stack

All issues in registrystack/registry-stack

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.