29k Sentry events from workflow rows orphaned by our own namespace rename

What is failing. TELECOM-COMPARATOR-NT — Error: Class "App\App\Monitoring\Phones\Workflows\ProcessPhonesWithEcommerce" not found, thrown from Workflow\Watchdog::recover(). 29,493 events, first seen 2026-05-11, 3,635 of them in the last 14 days — 98% of telecom-comparator's entire error volume, and the largest single error source across all three repos.

Root cause, and it is ours. App\App\Monitoring\… was the correct FQN of that class until 2026-03-26: psr-4 mapped "App\\": "app/" and the file sat at app/App/Monitoring/…. Commit 6828a219f (PR #446, "Remove double App/App directory nesting") moved it under psr-4 "App\\": "app/App" and rewrote the declaration to namespace App\Monitoring\…. Every workflows row persisted before that date still stores the old class string. grep -rn 'App\App\' over app/ src/ config/ database/ routes/ returns nothing, so no code is producing that name today — the only remaining source is data.

Why it grows instead of plateauing. Watchdog::handle() selects status = 'pending' AND updated_at <= now - timeout AND arguments IS NOT NULL, and recover() does new $storedWorkflow->class(...) — which throws before the $storedWorkflow->touch() that would advance updated_at. So the same fixed set of rows is re-selected and re-thrown on every sweep, forever. The L12 upgrade (1faeb6547, 2026-03-20, PR #434) took laravel-workflow 1.0.53 → 1.0.70, which is where the Watchdog sweeper arrived — hence rows orphaned in March that only began erroring in May.

The fix, written 2026-08-31. database/migrations/2026_08_31_000001_fail_orphaned_pending_workflows.php flips status from pending to failed for pending rows older than a day whose class no longer class_exists(). Nothing is deleted, so the five workflow_* cascade children and monitoring_analyses.stored_workflow_id are untouched, and both Watchdog entry points stop selecting the rows.

What a human still owns: deploying it, and confirming those five-month-old pending monitoring workflows carry no business meaning worth resuming. Remapping the class string instead would resume five-month-old monitoring runs, which is very likely worse than dropping them.

This is not OS-001. The package is the messenger, not the cause. See OS-001 for the separate and genuine question about staying on an abandoned dependency.

Answer (2026-09-01, users/108934946863892655718) : "It was deployed, checked on Sentry and it's all good now" — the migration (2026_08_31_000001_fail_orphaned_pending_workflows.php) is live and the TELECOM-COMPARATOR-NT event volume has stopped.