Release v1.1.2 · renatobo/TelegrARM

New Features

Queued delivery payloads are stored in randomized, non-autoloaded options instead of transients, so they survive an object cache flush between the moment an event is queued and the moment WP-Cron delivers it. Only the opaque ticket is still passed as a cron argument, so member data stays out of the autoloaded cron option.
A daily cleanup event removes payloads whose delivery never ran, which options need because they do not expire on their own.
Payloads are kept for three days rather than six hours. WP-Cron only runs on visitor requests, and on a low-traffic site six hours could elapse before anything triggered the queue.
Debug logging now records when a delivery is queued and when it is sent, and every drop path reports the method and target. An empty log previously could not distinguish an event hook that never fired from a payload that was queued and then lost.

Fixed queued notifications being silently dropped when a persistent object cache was flushed after the event was scheduled. The cron entry survived in the database while the payload did not, so the delivery ran with nothing to send.
Fixed the pacing and retry paths deleting the payload of a delivery that was still scheduled. Those paths reuse the same ticket, and WordPress refuses to schedule a duplicate hook and argument pair within ten minutes, so a concurrent cron spawn could strand a live event.

No settings or data changes. Deliveries queued by earlier versions are still resolved from their transients and are processed without migration.
Background delivery still depends on WP-Cron. On a site with little traffic, configure a system cron to request wp-cron.php and set DISABLE_WP_CRON so notifications do not wait for the next visitor.