Bulk Agent Schedule Deletion Performance

Bulk agent schedule deletion was previously slow due to redundant per-row SELECT / DELETE loops and the same fetch running three times per agent. A race condition left orphan cron rows when agents shared expressions, and reassigned agents carried stale client IDs on their cron rows. Deletion now uses a single bulk SQL sweep, orphan cleanup runs once at the end, and cron rows are re-pointed to the correct client at agent-save time.

Problems and fixes

The following root causes were addressed:

Problem	Fix
The same agent-cron fetch executed three times per agent, causing three round-trips per agent in the batch.	Reduced to a single fetch and one emptiness check in both bulk-delete threads.
Orphan cleanup did a per-ID SELECT and one DELETE per ID, linear with cron count.	A single bulk DELETE sweeps all orphan rows in one statement.
A per-cron usage-count check raced when agents shared a cron expression, leaving orphan rows.	The agent loop only drops the agent-cron association; one bulk orphan sweep runs at the end.
Reassigned agents left stale client IDs on cron rows, so the bulk sweep missed or wrongly deleted them.	At agent-save time, cron rows are re-pointed to the new client in the same transaction.

Where the improvement appears

The faster bulk deletion and cleaner cron table are visible in the following locations:

Location	What changed
Bulk delete from Agent Schedule page	Completes substantially faster. One DELETE per batch instead of per cron row.
Cron schedule storage	No more ghost orphan rows after bulk delete; reassigned-agent rows are correctly attributed.
Server logs	Cron ID for every delete, orphan-sweep row count, and reassignment row count are all logged.

Note: No action is required. After upgrade, bulk deletes complete faster and the cron table self-cleans correctly.