Erase terminal-only review activity clocks at result expiry

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

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
postgresql, rust
Domain
backend, databases

Research direction

Start in crates/registry-casework/src/review.rs and trace the retention pass for casework_review_clock_occurrences, especially the existing carve-out for subject clocks that continue across review rounds. Add a Postgres retention test for a kind where terminalDays is less than accountabilityDays. Done means terminal-only activity occurrences are removed at result expiry while continuing subject clocks retain their latest-round binding.

Written by the indexing model from the issue text.

Description

An automated review of #1189 flagged a retention gap in the review retention pass. In crates/registry-casework/src/review.rs, casework_review_clock_occurrences rows are deleted only where accountability_retained_until <= now, while the request context, tasks, drafts and history are scrubbed at the earlier result expiry.

Failure scenario: a review kind configured with terminalDays < accountabilityDays keeps completed activity-clock rows until the later accountability deadline. Those rows still carry the source, subject type and subject identifiers, the clock policy and the evaluated effects, so source-linked review data survives well past the declared terminal retention, potentially by years at the allowed bounds.

Suggested fix:

  • Delete terminal-only activity occurrences at result expiry, keeping the existing carve-out for subject clocks that genuinely continue across review rounds (those move their request binding to the latest round).
  • Add a Postgres retention test for a kind with terminalDays < accountabilityDays.

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

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.