BReg check_registry_audit doc comment still says a torn final entry blocks doctor
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 86/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- documentation
Research direction
After PRs #1712 and #1701 merge, open crates/registry-breg/src/startup.rs and read the check_registry_audit comment around lines 890-894. Reword it so it identifies the unwritable directory and other check_writable refusals as blockers, while removing the claim that a torn final entry blocks doctor.
Written by the indexing model from the issue text.
Description
Once PR #1712 merges, the doc comment on check_registry_audit in crates/registry-breg/src/startup.rs (lines 890 to 894 on main) is false:
a torn final entry or an unwritable directory there blocks an operator command exactly as one in the runtime's own destination would, so doctor must refuse it too instead of reporting a clean audit dependency.
PR #1712 (#1614) makes the shared writer recover a torn final line at open (the torn bytes go to an owner-only <path>.torn side file), and FileDestination::check_writable now accepts a torn final line without changing anything. So a torn final entry no longer blocks an operator command or doctor; only an unwritable directory (and the other check_writable refusals) still do.
Fix: reword the comment to name what still blocks. PR #1712 left it alone because PR #1701 is changing crates/registry-breg; do this after both merge.
Refs: #1614, #1712.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 7h 46m
- Merged PRs (30d)
- 199
Getting set up
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
-
area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1699 ·
Maintainers usually reply within 1 day
-
area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
registrystack/registry-stack#1682 ·
Maintainers usually reply within 1 day
-
area:casework bug criticality:p3 triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 88/100
registrystack/registry-stack#1669 ·
Maintainers usually reply within 1 day
-
area:evidence bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
registrystack/registry-stack#1665 ·
Maintainers usually reply within 1 day
-
Evidence: OPERATOR-CONTRACT says audit sequence numbers restart, but the .seq companion keeps themOpenagent-ready area:docs area:evidence criticality:p3 documentation triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1647 · 1 comment ·
Maintainers usually reply within 1 day
All issues in registrystack/registry-stack
Similar issues
-
`sysknife history --help` says --since takes ISO-8601, and the parser refuses offsets and bare datesOpenbug easy good first issue help wanted
Difficulty 1/5 1-3 hours Newbie friendliness 94/100
lacs-project/sysknife#519 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
documentation
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
lbjlaq/Antigravity-Manager#3539 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
stratum-mining/stratum#2407 ·
Maintainers usually reply within 2 days