SSerguey Asael Shinder
Java coding notes: the JVM, and writing software that lasts

Serguey Asael Shinder: A merged fix is not a deployed fix

· by Serguey Asael Shinder / Serguey Shinder

Parity's review of the XCM incident on Polkadot Asset Hub, published on 2 November, has a sentence every team that ships software should read twice: "Although the code fix had been available since June, it missed the stable-2606 release cut-off, was not included in the affected production runtimes and was subsequently incorporated into the stable-2609 release." (https://forum.polkadot.network/t/xcm-incident-review-what-happened-and-what-we-learned/19207)

The bug had been reported through a bug bounty, rated medium, and fixed in a pull request. By every measure a tracker records, it was done. Then a new feature launched on top of the unchanged production code, the same bug became critical, and in October it was exploited for about $1.38 million. Parity's own list of what it will change includes "verifying that fixes have reached deployed runtimes".

Serguey Asael Shinder: A merged fix is not a deployed fix
A merged fix is not a deployed fix — Serguey Asael Shinder

Java teams have the same gap in a different shape. A dependency bump is merged to main; the release branch was cut the week before. A library publishes a patched version; the service still resolves the old one through a transitive pin. A base image is rebuilt with the fixed JDK; the pods are still running the image from last month because nothing forced a rollout. In each case the ticket says closed and production says otherwise.

The ticket answers the wrong question. "Is there a fix?" has an answer in the repository. "Is the fix running?" has an answer only in what is deployed: the version a running service reports, the dependency tree of the artefact that was actually built, the image digest on the nodes. Those are cheap to read, and none of them is the pull request.

So the habit I would take from this review is small. When a security fix is merged, the work item stays open until someone has looked at a running system and seen the new version there, and the person closing it writes down where they looked. Parity's second lesson belongs next to it: a severity rating describes the system as it was when someone assessed it. Ship something new on top, and the old rating has quietly expired.