Evidence: OPERATOR-CONTRACT says audit sequence numbers restart, but the .seq companion keeps them
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- backend, documentation
Research direction
Start by inspecting crates/registry-platform-audit/src/writer.rs to verify how the .seq companion determines the next sealed-segment number, then compare that behavior with the retention guidance in docs/site/src/content/docs/operate/retention-and-persistent-state.mdx. Update the audit-section sentence in products/evidence/OPERATOR-CONTRACT.md and retain the archive-keying advice only if the verified behavior supports it.
Written by the indexing model from the issue text.
Description
products/evidence/OPERATOR-CONTRACT.md (audit section) says: "Sequence numbers restart after retention has deleted every sealed file and the process restarts, so archives must not be keyed on the sealed file name alone." The shared writer now records the next sealed-segment number in a .seq companion (crates/registry-platform-audit/src/writer.rs), and docs/site/src/content/docs/operate/retention-and-persistent-state.mdx describes numbering that survives retention. Verify the writer's behavior and correct the contract sentence (and keep the archive-keying advice only if it still holds).
Found while writing the #1415 runbooks.
- 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 criticality:p3 documentation triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 86/100
registrystack/registry-stack#1713 ·
Maintainers usually reply within 1 day
-
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
All issues in registrystack/registry-stack
Similar issues
-
backend::vllm diffusion multimodal
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lambdaclass/ethrex#7329 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
shadowsocks/shadowsocks-rust#2186 · 1 comment ·
-
C-bug S-awaiting-triage
Difficulty 1/5 Under an hour Newbie friendliness 92/100
juspay/hyperswitch#14479 ·
Maintainers usually reply within 1 day