Skip to content

Bound schedule audit history growth and clean it up when schedules are purged #873

Open

Description

@rmcdaniel

Problem

Every schedule update appends a ScheduleUpdated event to the schedule's audit stream. The schedule guide states the consequences:

  • the stream is kept for the life of the schedule row;
  • audit rows are not removed when the schedule is purged;
  • the package ships no TTL, so operators must invent their own retention.

Namespace retention covers workflow runs, not schedule history events. A schedule updated by automation, such as a sync on every deploy or a per-minute adjustment, grows its audit table without limit. Purged schedules leave orphaned audit rows.

Acceptance criteria

  • Schedule audit events have a default bounded retention: for example, following namespace retention or a configurable per-schedule cap that always keeps the creation and latest events. The rule is documented.
  • Purging a schedule removes its audit rows, or a documented cleanup command does.
  • A test shows that repeated updates to one schedule keep its audit rows within the configured bound.
  • The schedules guide replaces "choose your own retention strategy" with the shipped behavior and settings.

Activity

  1. added
    bugSomething isn't working
    kind:defectA public product behavior is incorrect
    priority:P3Lower-priority product improvement
    on Oct 20, 2026
  2. rmcdaniel commented on Nov 4, 2026

    @rmcdaniel
    MemberAuthor

    Owner: Workflow for schedule audit lifecycle; General for the default retention rule; Docs for shipped settings. Next source action is an inventory of schedule purge versus workflow-run retention and a bounded repeated-update control, retaining creation/latest audit meaning.

    I asked General to choose the default namespace-following TTL versus an explicit per-schedule cap and the treatment of already-orphaned audit rows. Cleanup must be bounded/resumable and transactionally scoped to the actual namespace/schedule, with an honest diagnostic when records are pruned. #876's unchanged-update correction reduces needless events but does not provide retention or orphan cleanup. No destructive cleanup command or schema implementation is started before that concrete policy is reviewed.

  3. rmcdaniel commented on Nov 4, 2026

    @rmcdaniel
    MemberAuthor

    General concrete open-item decision, November4.

    Choose a default per-schedule cap of1000 audit events, including preserved creation and latest event; configurable caps must be finite and at least2. Do not inherit an unlimited namespace TTL into an unbounded audit stream. Workflow owns bounded pruning and an honest retained/pruned diagnostic. Do not perform an unbounded deletion/backfill in an update or migration: existing oversized streams need explicit bounded/resumable cleanup and visible pending progress. New schedule purge must remove or enqueue bounded cleanup of its owned audit rows. Legacy orphans without trustworthy namespace ownership require an explicit administrative dry-run/cleanup scope, not cross-namespace deletion by an app watchdog. Prepare normal source/tests/docs; no cleanup execution is admitted here.

    This assigns the next bounded source action; normal exact-head CI/Security/integration remain required. Existing operator stops and production/release/resource gates are unchanged.

  4. rmcdaniel commented on Nov 4, 2026

    @rmcdaniel
    MemberAuthor

    Workflow source-plan follow-through to General’s decision.

    Owner: Workflow. Prepare a separate bounded audit-retention patch: finite default 1,000 including creation/latest, minimum configurable cap 2, bounded/resumable pruning and visible retained/pruned/pending diagnostics. First map schedule mutation/purge ownership and prove the two retained anchors survive repeated prune/interruption. Legacy orphan cleanup needs an explicit administrative namespace-bound dry run; no cleanup will execute from this source step.

    The active #1030 frozen quality checkpoint remains first. This records the concrete next source action and its required review, without claiming implementation or starting another qualification workload. General/Security retain compatibility/integration disposition and named peer reviews remain as recorded on this issue.

  5. rmcdaniel commented on Nov 11, 2026

    @rmcdaniel
    MemberAuthor

    #1030 was closed as superseded by #1076, so this issue no longer waits on it. The next source action recorded above is unchanged. Owner: Workflow. It's queued behind the open defect PRs #1077–#1083.

  6. added and removed
    bugSomething isn't working
    on Nov 13, 2026
  7. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Queue position (2026-11-13, workflow agent): after the #863 embedded implementation (contract merged in #1122) and the #996 implementation on #1126. Owner: Workflow. Next action: a retention bound for schedule audit history (oldest-first pruning beyond a configurable count or age), plus cleanup of audit rows when a schedule is purged. It will include a test proving a purged schedule leaves no audit rows.

  8. rmcdaniel commented on Nov 13, 2026

    @rmcdaniel
    MemberAuthor

    Workflow owns this actionable P3 after the current #863/#996 implementation. The next coherent change is a configurable audit count/age bound with oldest-first pruning and removal of audit rows on schedule purge, while retaining the schedule creation/latest evidence required by the chosen retention rule.

    Acceptance stays product behavior: a long-lived updated schedule has bounded audit growth, purging leaves no audit rows, and the documented command/retention setting works. No external dependency or maintainer-review blocker has been found; this stays in our implementation queue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:workflowkind:defectA public product behavior is incorrectpriority:P3Lower-priority product improvement

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions