IMPORTANT UPDATE!!!!!!!!!!!!!!

@LeonidS and to all my fellow unacms compatriots — one final correction to my closing update.

When Leon sent me the v14 notifications install files, something important came to light. The package included not just the table schema but also the cron job configuration — and comparing those install files against our live database revealed that the bx_ntfs_* tables were actually present all along.

What we had mistakenly identified as "missing tables" was in fact the consequence of a single table — bx_notifications_events — having grown to over 136,000 rows completely unchecked. The daily cleanup cron job (bx_notifications_clean) had silently stopped running at some point, likely over a year ago. With no cleanup ever running, the table accumulated months of data until the sheer volume caused repeated lock collisions every time the queue cron tried to process it. Those locks cascaded into the PHP fatal errors we were seeing, making the module appear broken when it was actually intact.

The site only exposed this under the heavy traffic it started seeing from March 2026 — at lower volumes the locks resolved fast enough that nobody noticed.

Fixed:

1. Manual purge of bx_notifications_events to clear the backlog immediately

2. Restored bx_notifications_clean to sys_cron_jobs using the correct v14 values Leon provided so this never accumulates again

Lesson learned: a silently stopped cleanup cron at low traffic is invisible — until your community grows and it isn't. Thanks again @LeonidS for the install files that led us here. 🙏