Containers: repetition, revisions and promotion

Restart policy

In ACI, choose policy according to the intended process outcome. Always restarts even after success. OnFailure expresses repetition after error exit, suitable for tasks that should stop after success.

Do not use Never as a universal guarantee against repetition under every platform failure. In all cases, process state is not a distributed transaction with systems it received from or modified.

Effect and checkpoint

A batch can write an order and fail before its checkpoint. Restarting does not undo that order and can repeat it. Define stable operation identity, deduplication and reconciliation of uncertain states.

A nonzero exit code describes process failure, not proof of absent effects. In the exercise, identify the already-created order, decide whether repetition is safe and explain what must be recorded for the incident recipient.

Change scope

In Container Apps, revisions are immutable. Template changes such as image and scale rules create revisions; application configuration changes can affect all revisions without creating another. Changing a secret requires preparing consuming revisions’ restart so processes recognize the new value.

Do not infer failure solely because no new revision appeared. Record what configuration changed and in which processes it was activated.

Traffic and evidence

Single revision mode keeps the previous revision until the new one is ready. Multiple revision mode allows control of active versions and distribution. A label has its own URL and routes requests to the designated revision independently of main-URL percentages.

One hundred requests to the qa label do not measure the main URL’s 90/10 distribution. Choose the entry point according to the hypothesis: checking one version, measuring distribution and accepting the whole service are different trials.

Common pitfalls

Avoid inferring exactly-once from restart policy, a new process from an updated secret, or global distribution from label requests.