# Notifications Rollback Plan

## Objective
Safely roll back the custom notification system without breaking alert generation or tenant isolation.

## Preconditions
- Queue workers are running under supervisor/systemd with identifiable process names.
- Backup of tenant DBs and central DB exists.
- Deployment window approved.

## Step-by-step Rollback

1. Stop notification queue workers only.
- Stop workers for queue `notifications`.

2. Disable dispatch triggers.
- Temporarily comment/disable `ProcessAlertNotificationsJob` dispatch call in `GenerateAlertsJob`.
- Disable command usage `notifications:dispatch` in scheduler (if scheduled).

3. Keep data immutable.
- Do not drop `notifications`, `notification_logs`, `notification_counters` immediately.
- Keep tables read-only for forensic analysis.

4. API rollback.
- Remove or feature-flag routes under:
  - `/api/notifications/*`
  - `/api/superadmin/notifications`

5. Counter fallback.
- UI bell should fallback to zero or old Laravel notifications source (feature-flag based).

6. Central mirror rollback.
- Stop `MirrorNotificationEventJob` workers.
- Keep `central_notification_events` for audit trail.

7. Validate system.
- Run alert generation command and confirm it completes:
  - `php artisan alerts:generate {project_id}`
- Confirm tenant dashboards unaffected.

## Optional Hard Cleanup
Only after post-rollback signoff:
- Drop tenant notification tables per tenant DB.
- Drop central mirror table migration if no retention requirement.

## Verification Checklist
- Alerts still generate.
- No tenant data leakage.
- No queue backlog growth in notifications queue.
- UI stable and no 500 errors on notification endpoints.