Urgent fix — Friday 31 July
v2.0.1Found after this morning's release. Fixed and on the live store the same morning, before the store opened. One change.
Summary
A customer who went back to correct their shipping address could not correct it. The site accepted the new address on screen and then used the old one.
What they typed appeared in the field, so nothing looked wrong. But the address that went to the carrier, onto the review page and onto the order was the one they had come back to change. Two fields did update — the ZIP and the phone — so what a customer saw was a mixture: the new ZIP beside the old street.
Nobody was quietly shipped to the wrong place. The review page honestly showed the old address, so an attentive customer saw it before paying. But they had no way to fix it, which means an abandoned order or a phone call — either way we lose the sale.
The warning we show for PO Box addresses was reading the same stale information, so on this path the one address type the carrier cannot deliver to went through unwarned.
This did not come from this morning's release. Denis reproduced it on the live store and on the test site before the release went out, so it has been there for some time. It is not something we broke today.
It also did not wait for next Friday. It is on the money path — a customer cannot complete an order the way they intend — so we treated it as urgent rather than holding it for the next release. That is a change outside the normal procedure, and it is recorded as one.
The change — the four things, as always
- What it is
- When a customer goes back to fix their shipping address, the address they type is now the one that is used — for the carrier, for the review page and for the order. Filling the address in for the first time is unchanged, and accepting a carrier's suggested correction still updates the fields on screen.
- How we test it
- Reach the review step, go back to shipping, change the street, continue. The new street has to appear everywhere downstream, with no part of the old address surviving anywhere in what is sent.
- The evidence
- Denis reproduced the fault twice on the live store and on the test site before writing the fix. Two new tests drive a real browser through that exact journey and check what the site sends. Both were shown failing on the old code with the reported symptom, and passing on the new code. The full gate ran — nineteen jobs, all green — and we confirmed by reading the log that these two tests actually ran rather than being quietly skipped. The code that went to the live store is byte-for-byte the code that passed.
- Roll back or fail forward
- Roll back, in one button. It is a single screen with no database change behind it, so undoing it restores exactly today's fault and nothing else. We are not planning to.
What v2.0.1 is — the exact thing to go back to
Only the storefront moved. The other three parts of the store are still what v2.0.0 pinned this morning.
| Storefront | f77f16fb | Changed. Vercel keeps this morning's build, so going back to v2.0.0 is one button. |
|---|---|---|
| Search | search-api-00017-zuy | Unchanged. |
| Services | 4b96c314 | Unchanged. |
| Database | 20260731074650 | Unchanged. |