Persist and compare the retained review-authority endpoint/profile binding

Open
#1,201 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend

Research direction

Start with the BReg review-authority startup check and the retained-submission state, then read validate_retained_completion_destinations in crates/registry-casework/src/runtime.rs around lines 197-220. Resolve whether retained work should be refused until it drains or migrated deliberately, and add tests covering the accept/refuse paths for both runtime checks.

Written by the indexing model from the issue text.

Description

Finding

From the PR #1189 review (Codex thread 95, P2):

When an operator restarts with the same authority and producerId but changes its endpoint or requester profile, the BReg review-authority startup check still accepts the configuration even though pending submissions retain only the logical IDs. The worker then sends the stored create request, cancellations, and result polls through the replacement binding, which can strand durable work or disclose proposal identifiers and initiator data to a different service.

Direction

Persist the non-secret endpoint/profile binding alongside the retained submissions and compare it at startup: either refuse rebinding until retained work drains, or migrate deliberately. There is a twin of this pattern in crates/registry-casework/src/runtime.rs (validate_retained_completion_destinations, around lines 197-220) that should be treated as part of the same design decision, not fixed independently.

Estimated scope: a small persisted binding record, a startup comparison, tests for the accept/refuse paths on both sides. Roughly 150-250 lines including tests.

Disposition

Deferred from PR #1189 to keep that change scoped; the PR hardens the client and runtime contract surfaces that were correctness bugs today. This one needs a persisted-state design call (refuse-and-drain vs migrate) that deserves its own review.

Dominant language
Rust
Stars
2
Forks
0
Avg merge
3h 45m
Merged PRs (30d)
134

Contributor guide

Open the contributing guide

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.