¶ Database row
Inspect the scheduled-message row state first. The durable record tells you whether ReplyBox still believes the message is queued.
Operations
¶ Scheduled Message Recovery
Recover the scheduler, not the transport. A small percentage of scheduled messages can remain queued after the BullMQ job disappears and no error is raised.
Symptom: queued schedule, missing job
Owner: API orchestration
Send through producers
Rule
¶ Recovery logic belongs beside orchestration.
Scheduled messages, flow runs, and broadcasts decide when to send inside API workers. Recovery should re-create or resume that orchestration state, then call the same producer functions used by synchronous endpoints.
Failure shape
¶ The row survives, the queue job does not
A scheduled message can still look queued in application state while its BullMQ job is gone. The dangerous part is the silence: no raised error, no obvious failed job, and no automatic send.
Triage
¶ Four checks before changing anything
Keep the investigation in the same order every time so a missing job is not mistaken for connector or WhatsApp behavior.
Inspect the scheduled-message row state.
Inspect BullMQ for the expected job.
Confirm whether an orchestration worker is running.
Verify that the worker calls the same producer functions used by synchronous endpoints.
Recovery path
¶ Resume the scheduler, then enqueue normally
¶ Prove the stuck state
Capture the scheduled-message row state and the missing BullMQ job evidence together.
¶ Confirm worker ownership
Scheduled recovery belongs to API orchestration. The connector should remain a consumer of producer-created WhatsApp work, not the owner of scheduler repair.
¶ Re-enter the producer path
After recovery decides the message should send, it must call the same producer functions as the synchronous endpoints.