Activity cleanup

P4 Code Review can automatically remove old activity feed records stored as swarm-activity-* keys in P4 Server’s db.nameval table. On high-volume systems, these records can grow without bound over time. This feature allows administrators to enforce age-based retention.

The feature is disabled by default. Existing installations see no behavior change unless retention_lifetime is explicitly configured.

Configuration section

Place a configuration example near the top of the page, immediately after the overview.

'activity' => (
    'cleanup' => (
        'retention_lifetime'  => null,     // e.g. "30 days", "6 months", "1 year". null = disabled (default)
        'max_delete_per_run'  => 50000,    // max records removed per sweep
        'batch_size'          => 1000,     // page size used internally
        'sweep_interval'      => 86400,    // seconds between sweeps (24h)
        'drain_interval'      => 300,      // seconds; shorter interval while backlog remains
    ),
),

Key	Default	Description
`retention_lifetime`	`null`	Minimum age before an activity record becomes eligible for cleanup. This must be a `DateTime`-style offset string such as `"30 days"`, `"6 months"`, or `"1 year"`. A null or empty value keeps the feature disabled.
`max_delete_per_run`	`50000`	Upper bound on the number of records deleted during one sweep run. Prevents large backlogs from monopolizing the worker or placing excessive load on P4 Server.
`batch_size`	`1000`	Internal paging size used while locating and deleting eligible records.
`sweep_interval`	`86400`	Normal interval, in seconds, between automatic sweep runs.
`drain_interval`	`300`	Shorter interval used when more deletions remain after a sweep run, allowing the system to drain a backlog faster. The effective interval is capped by `sweep_interval`.

retention_lifetime must be a positive DateTime-offset string.

A value such as "0 days" should be rejected to avoid accidental removal of all retained history.

How cleanup works

A recurring background sweep removes the oldest eligible activity records first once they are older than the configured retention lifetime.
Each run is capped by max_delete_per_run.
If more eligible records remain, the next sweep runs after drain_interval. Otherwise the normal sweep_interval applies.
The process resumes from prior progress rather than repeatedly rescanning already-deleted history.
Deletion also removes associated search-index entries.

Do not use raw key deletion

Direct use of p4 key -d or p4 key -D for these records leaves orphaned index rows behind and can corrupt activity feed and p4 search behavior.

User impact warning

Enabling retention_lifetime is destructive to activity history. Once cleanup runs, activity events older than the configured cutoff are permanently removed from the activity feed and history views. Use the dry-run endpoint first to understand the impact.

Recoverability and disk-space reclamation

Deleting an activity key is a P4 Server key deletion, not an obliterate.
Deleted records remain recoverable from the journal or checkpoint history until a checkpoint and restore cycle compacts the tables.
Cleanup frees space for reuse within db.nameval and related index storage, but physical database files on disk do not shrink immediately.
To reclaim disk space after a large initial cleanup, administrators should schedule a checkpoint and restore.