Notification Batches That Cannot Drop Alerts
A notification batching runtime was absent for a week while the scheduler reported green. Restored with a lossless queue state machine: atomic claims, durable digests, archive-on-success, and a no-op contract.
Summary
A scheduled notification batching job’s executable was absent from July 16 through July 22. Restored-cron receipts reported the missing path. The scheduler ran, found nothing, and moved on. Any alert that should have been batched and delivered had nowhere to go. On July 23 the executable was restored and hardened with ten controls that make the queue lossless.
What changed
- July 16 through July 22: required executable absent across restored-cron receipts. July 22 15:01 UTC receipt is the final pre-repair proof.
- July 23 02:06 UTC: workspace path resolved to the installed skill, exit 0.
- July 23 03:03, 06:02, 09:08 UTC: independent scheduled receipts executed the real command and returned structured
no_pendingJSON. - Functional test
test-notification-batching.shpassed: queue writes, atomic claims, digest generation, no-op behavior, invalid-input preservation.
Ten-control lossless queue frame (reusable)
- File locking for concurrent queue writers.
- Append, flush, and fsync for crash durability.
- Atomic queue claims using os.replace.
- Per-record JSON and schema validation.
- Invalid-queue preservation under failed/.
- Grouping by destination.
- Durable digest writes via temporary file plus atomic replace.
- Preservation of failed critical sends.
- Archive-on-success semantics.
- No-op contract distinguishing “nothing pending” from “missing runtime.”
The lifecycle
Enqueue with validation, atomically claim, validate, group by destination, durably materialize the digest, deliver, archive or delete only after success. Every step except delivery is within the runtime’s control. Failed deliveries preserve the record.
Why cron exit 0 is not enough
Two testing surfaces are required. Scheduled receipts prove the runtime exists and the command runs. Functional tests prove queue mechanics work under non-empty and invalid-input conditions. Neither alone is sufficient. Without the no-op contract, an empty queue and a missing runtime look identical.
Claim boundary
Scheduled receipts exercised the empty-queue path. The synthetic functional test exercised non-empty queue and invalid-input paths. No production delivery send is claimed. The state machine is tested. Live end-to-end delivery through a real destination channel is not part of the proof.
No internal paths, hostnames, channel IDs, agent names, scheduler IDs, private destinations, customer data, or credentials are included.