Upgrading is designed to change nothing about how your existing schedules behave until you deliberately change something.
The Guarantee #
| Preserved across an update | |
|---|---|
| Each series’ exact next target | Its progress and successful count |
| Its stored payload snapshot | Its cadence and end condition |
| Its lifecycle state | Its attempt history |
Migration itself submits nothing. Neither does activation.
The Missed-Run Setting #
The Missed runs setting defaults to “Run one missed occurrence, then continue” — which is exactly what every feed already did before the setting existed.
So updating changes no behaviour until you deliberately choose the skip policy and save.
Existing series keep the policy recorded in their own snapshot. To move them to a new one, apply the saved feed schedule to them.
Timing Evidence #
The timing-explanation feature reuses the existing attempt-context column, so it needs no schema change and no feed-settings migration.
| Behaviour | Detail |
|---|---|
| Existing series | Gain timing evidence on future attempts only |
| Their target, cadence, progress, payload and state | Unchanged |
| Earlier history | Never rewritten |
| Older attempts | Not retroactively classified |
The Operational Storage Migration #
The broader reliability upgrade migrates legacy operational rows, not your saved feeds.
| What migration does | What it preserves |
|---|---|
| Captures recurrence as a series snapshot | The exact next target |
Converts legacy pending rows to scheduled |
The successful count |
| Recovers stale processing claims | The stored payload |
| Pauses series whose feed is inactive | |
| Ends series whose feed was deleted | |
| Flags historical failures for review |
It is restartable, so an interrupted migration can safely continue.
Two careful behaviours worth knowing #
- Historical failure data is flagged conservatively. The plugin does not assume an old failure log represents a consecutive run, because that would wrongly trip failure thresholds on upgrade.
- Invalid migration data stays visible as a migration problem rather than being silently replaced with a guess.
After the first worker pass #
Once the worker runs, an eligible overdue series can create one child entry and advance to a future target. It never replays every missed occurrence.
Schema Repairs #
A later schema version repairs incomplete earlier installations — for example one missing the last-outcome column — while preserving existing normalized series, attempts and canceled states.
Repairing the schema does not reconcile an earlier ambiguous submission. A series blocked by a storage failure stays blocked until its children and attempts are reviewed.
What an Ordinary Feed Save Still Does #
This hasn’t changed and won’t:
| Feed save | Effect |
|---|---|
| On new series | Applies fully |
| On existing series | No effect on their recurrence |
| Feed activation | Takes effect immediately, at runtime |
| Live submission-related settings | Keep their runtime behaviour |
A schedule snapshot is a snapshot of the schedule, not a freeze of every feed setting.
To change existing series’ recurrence, apply the saved feed schedule with its preview and confirmation. To move only one series’ next date, use Change next submission.
A Post-Update Checklist #
- Open GravityOps → Recurring Submissions → Queue and confirm the worker is healthy with a recent heartbeat.
- Check that Scheduled and Needs attention counts look like they did before.
- Spot-check one series: its next target, cadence and progress should be unchanged.
- Read any migration message shown in worker health.
- Only then consider changing settings — one change at a time, with a preview.
