Pointing the address back at an earlier version
When a version is wrong, recovery is one deployment act: the stable address is pointed at an earlier published version, exactly as it was. Nothing is rebuilt.
· 4 min read
IN SHORT
When a version is wrong, the operator points the stable address back at an earlier published version. Published versions are frozen and kept, so the earlier one is exactly as it was when it last ran. The site's applications keep calling the same address and now reach the earlier version. The act is recorded with who did it and when.
A new version goes live and the drafts are wrong. A clause is misread, a step was placed badly, a tool is being called that should not be. The operator has one decision to make, and it is not a hard one. Point the stable address back at the earlier version. The agent returns to what it was doing before.
What pointing back means
Deploying points a stable address at a published version. Pointing back is the same act in the other direction: the operator moves the address from the current version to an earlier published one. The applications that call the address do not change. The earlier version does not change. Only the pointer moves.
Because published versions are frozen, the earlier version is exactly as it was when it last ran. There is no rebuild, no republish, and no chance it comes out differently. The agent behind the address drafts, waits, and calls exactly as it did before the wrong version was deployed.
Why this is simple on Czar
Three properties of the platform make rollback a single act.
Versions are frozen. Publishing fixes a design and nothing can edit it afterwards. The earlier version has not drifted since it was last live.
Versions are kept. Publishing a new version does not discard the old one. Every published version of an agent remains available to point at.
One version is live at a time. The address points at exactly one version, so moving it is moving one pointer. There is no traffic to rebalance and no overlap to resolve. The article One live version at a time explains why the platform insists on this.
The sequence
When a version is found to be wrong, the operator typically does the following. Turn the address off, so no new packets enter the wrong version. Let in-progress runs finish; they complete under the version they started with. Point the address at the earlier version. Turn the address on. New packets now reach the earlier version.
Turning the address off first is not strictly required, since pointing back on its own routes new packets to the earlier version, but it gives a clean boundary in the record between the last run of the wrong version and the first run of the restored one. Turning a live address on and off covers that control.
The deployment history for the address gains an entry: the address was pointed from the wrong version to the earlier version, by this operator, at this time. Runs that happened under the wrong version keep their records and name that version. Runs after the move name the earlier version.
An auditor reading the history sees the forward deployment, the period under the wrong version, and the rollback, each with a name. The runs during that period can be opened one by one. Nothing about the episode is hidden by the recovery.
The wrong version stays available
Pointing back does not delete the wrong version. It remains a published version, available to open and inspect. The operator or developer can read it on the canvas or in the file and find what went wrong. If the problem was a bound, they can see which. If it was a step placement, they can see where.
This is useful for the fix. The operator edits the draft, which may begin from the wrong version or from the restored one, corrects the problem, and publishes a new version. When ready, they point the address at it. The wrong version is still there in the history as the thing that was tried and withdrawn.
What about the runs that already happened
Pointing back prevents new runs under the wrong version. It does not undo the ones that happened. Those runs have records. Each shows the inputs, the passages, the draft, the reviewer's decision, and the call. The desk can open them and decide what needs correcting.
In many cases the waiting step limited the damage. A reviewer who saw a wrong draft and stopped the run prevented the call. The record shows the stop. For runs where the reviewer approved, the record shows what was approved and what call was made, which is what the desk needs to put things right. Opening a finished run the next morning describes that review.
The reason rollback on Czar is worth describing is not that it is clever. It is that it is small. One pointer moves, one entry is written, and the agent is back to a known state. The site is not asked to trust that an old design was rebuilt faithfully, because nothing was rebuilt. The platform page describes how versions and addresses sit within the appliance.
Questions this raises
- How far back can the address be pointed?
- To any published version of that agent. Published versions are kept, so an operator can point the address at the one before the wrong version, or at an earlier one if the problem was introduced some time ago. Each move is recorded.
- Do runs that the wrong version handled get redone?
- Not automatically. Their records exist and name the wrong version, so a reviewer can open each one and see what happened. The desk decides how to handle any outcomes that need correcting. Pointing the address back prevents new runs under the wrong version; it does not alter past ones.
- Does rolling back require the admin?
- No. Pointing the address is an operator act, like deploying forward. The admin decides who holds the operator role, but the operator does not need a separate approval to point back. The move is written down with the operator's name.
KEEP READING