Aglet

Verify compatibility after correcting version skew

Verification must cover the boundary that exposed the skew. Confirm served versions and then exercise or observe the same interaction under the reviewed release state. A version label becoming uniform is insufficient if queues or long-lived workers still carry the old behavior.

Check whether the outcome improved

  1. Recheck all participants

    Record current versions for services, workers, environments, repository commits, and artifacts that participate in the path. Include delayed or persistent processes where the original incident involved them.

  2. Compare boundary outcomes

    Review representative requests, events, or jobs for successful parsing, completion, latency, retries, and downstream effects. Compare with the original failure and a known-good interaction where possible.

  3. Close the compatibility window

    Apply the declared checkpoint and record whether skew is gone, bounded and compatible, or still uncertain. Keep a follow-up if exposure or queue age means old behavior may reappear later.

What to carry forward

Verification should state aligned, compatible overlap, still skewed, or inconclusive with version and behavior evidence. Close only when the relevant participants and delayed paths are covered; uniform display labels alone do not prove compatibility. Replay the affected interaction with each relevant version pair and inspect both sides of the contract, including retries or queued delivery, before declaring the skew resolved.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow