Document the mixed revision state after a failed rolling swap #93

New issue

Open

opened 2026-10-09 10:54:02 +00:00 by ahmad · 0 comments

ahmad commented

2026-10-09 10:54:02 +00:00

Owner

Context

The review of #92 raised this, non-blocking. After a failed rolling swap, the services that are recreated in place already run the new revision, while the rolled service stays on the old one until the next deploy. That mixed state is expected, but the README doesn't say so, and someone diagnosing a failed deploy could mistake it for a separate fault.

Scope

In: one or two sentences in the deploy-vps zero-downtime section of the README.
Out: changing the rollout order.

Acceptance criteria

Given a reader of the zero-downtime section, when a rolling swap has failed, then the README tells them the other services are on the new revision and the rolled one on the old, and that this is expected.

### Context The review of #92 raised this, non-blocking. After a failed rolling swap, the services that are recreated in place already run the new revision, while the rolled service stays on the old one until the next deploy. That mixed state is expected, but the README doesn't say so, and someone diagnosing a failed deploy could mistake it for a separate fault. ### Scope - In: one or two sentences in the deploy-vps zero-downtime section of the README. - Out: changing the rollout order. ### Acceptance criteria - [ ] Given a reader of the zero-downtime section, when a rolling swap has failed, then the README tells them the other services are on the new revision and the rolled one on the old, and that this is expected.

ahmad added the

labels

2026-10-09 10:54:02 +00:00