Automatic retries
Scheduled deploys and automatic rollbacks often run when nobody is watching: at midnight, over a weekend, at the end of a sale. If your store can't be reached at that moment, MageDrop doesn't just give up. It tries again on a schedule you control, and emails you if it still can't get through.
What is retried
A scheduled run is retried when the problem is likely to pass:
- Magento can't be reached, or the connection times out.
- Magento answers with a server error, or says it's too busy.
- The store is in maintenance mode, for example during a deployment of your own.
- The run stopped part-way through, for example because the server it was running on restarted.
Errors that would happen again every time, such as an entity that was deleted in Magento, invalid data or a missing API permission, fail straight away so you can fix them.
Deploys and rollbacks you start yourself with Deploy now or Roll back are never retried automatically. You see the result on the release page as it happens and can try again with one click.
The retry schedule
By default, MageDrop waits 1, 5, 15, 30 and 60 minutes between attempts: five retries over about two hours. Each store can change this under SettingsScheduled runs:
- Retry automatically: turn retries off altogether.
- Wait before each retry: up to 10 retries, each between 1 minute and 1 day.
- Email the store owners when a scheduled run gives up: on by default.
Only store owners can change these settings.
Releases with an end time
A deploy is never retried if it would only go live after the release's Roll back at time. A weekend sale that couldn't start on time won't suddenly appear on Monday morning.
What you'll see
- While it waits: a scheduled deploy goes back to Scheduled (nothing from the release is live), and a scheduled rollback stays Live. The release page shows the error, which attempt failed and when the next one is due.
- Retry now brings the next attempt forward, once you know the store is back.
- Stop retrying marks the release Failed and leaves the store as it is. You can still deploy or roll back by hand.
- If it gives up: the release is marked Failed with the last error, and the store owners get one email with a link to the release.
Every attempt is recorded in the release timeline and the store's activity log.
Nothing is applied twice
A deploy is all or nothing. If an attempt fails part-way with an error, the changes it had already made are put back before it waits for the next attempt. If the run stopped altogether (the server running it restarted), the next attempt finishes the job. If there is no next attempt, the release page and the email say whether any of its changes are live, and you can roll them back by hand.
Sometimes Magento saves a change but the reply never arrives, for example when the connection drops at the wrong moment. MageDrop marks each change before it sends it, so the next attempt first checks what Magento already shows and doesn't send it again. A rollback that stops part-way carries on from where it got to.
Long deploys and busy stores
- One run per store at a time. If two releases on the same store are due together, the second waits until the first has finished. Releases on different stores run side by side.
- A release never runs twice at once, however many times it is triggered.
- Long deploys are never interrupted. While a deploy is running, the release page shows its progress (for example "12 of 28 items"). MageDrop only treats a run as stuck when it has made no progress for 10 minutes. It then counts as a failed attempt: a scheduled run is retried and carries on from where it stopped, and one you started yourself is marked Failed.