mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-16 16:45:07 +00:00
ignacionelson
cab9291d29
Failed queue jobs and read notifications both grow with use, and neither ever shrank on its own. The failed-jobs list waited for somebody to press "Delete all failed" — a fine tool for a backlog you are looking at, and the only thing that ever emptied it. Notifications had nothing at all: one row per recipient per event, kept for the life of the installation, on what is easily the fastest-growing table here. Both now have a retention window, set together on the Scheduler screen under Housekeeping, and a nightly purge that honours it. Thirty days for failed jobs and ninety for read notifications, and zero means keep everything — the explicit choice somebody makes when a failure is evidence rather than debris. Unread notifications are never deleted, whatever their age. A notification nobody has looked at is the one row in that table still doing its job, and somebody back from four months away should find their news rather than a clean slate. The activity log is untouched by any of this: it is an audit trail, and it is never pruned. Two things came out of building it. The API request log purge has been running nightly since it shipped without ever appearing on the Scheduler screen — so a failure of it was invisible on the screen that exists to make failures visible — and there is now a test asserting the screen's list and the schedule are the same list, because they had already drifted once and would again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
2.1 KiB
PHP
63 lines
2.1 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Modules\Notifications\Console;
|
|
|
|
use App\Modules\Notifications\InAppNotification;
|
|
use App\Modules\Platform\Settings\Setting;
|
|
use App\Modules\Platform\Settings\Settings;
|
|
use Illuminate\Console\Command;
|
|
|
|
/**
|
|
* Delete read notifications past the retention window.
|
|
*
|
|
* One row per recipient per event, and until now nothing ever removed
|
|
* one. On an installation where every share notifies a handful of people
|
|
* this is the fastest-growing table in the database, and the growth buys
|
|
* nothing: nobody scrolls a year back through a notification list.
|
|
*
|
|
* **Unread notifications are never deleted, at any age.** A notification
|
|
* nobody has looked at is the one thing in this table still doing its
|
|
* job, and an installation whose owner was away for four months should
|
|
* come back to their news rather than to a clean slate. The history is
|
|
* not an audit trail either way — the activity log is, and it is never
|
|
* pruned.
|
|
*/
|
|
class PurgeNotificationsCommand extends Command
|
|
{
|
|
protected $signature = 'projectsend:purge-notifications';
|
|
|
|
protected $description = 'Delete read notifications older than the configured retention window (runs daily)';
|
|
|
|
public function handle(Settings $settings): int
|
|
{
|
|
$days = (int) $settings->get(Setting::NotificationRetentionDays);
|
|
|
|
if ($days <= 0) {
|
|
$this->info('Notification retention is disabled; nothing pruned.');
|
|
|
|
return self::SUCCESS;
|
|
}
|
|
|
|
// Chunked for the same reason the API request log is: this is a
|
|
// high-volume table, and a single unbounded DELETE on a busy
|
|
// installation holds locks for as long as it takes.
|
|
$cutoff = now()->subDays($days);
|
|
$deleted = 0;
|
|
|
|
do {
|
|
$batch = InAppNotification::query()
|
|
->whereNotNull('read_at')
|
|
->where('created_at', '<', $cutoff)
|
|
->limit(5000)
|
|
->delete();
|
|
$deleted += $batch;
|
|
} while ($batch > 0);
|
|
|
|
$this->info("Pruned {$deleted} read notifications older than {$days} days.");
|
|
|
|
return self::SUCCESS;
|
|
}
|
|
}
|