Running the split across all 19,040,296 orders left 104 payments with two parent
orders in a 250,000-order sample. Every one of them is two orders of the SAME
client; cross-client sharing is gone entirely.
Attempting to split those too was wrong twice over. Both orders compute the same
name, so there is no second name to give a copy and the transaction conflicts.
And a copy would double that client's takings for the day — where Square splits
one tender across two of a client's own orders, one payment covering both is the
truthful record.
So the rule is now explicit: split per client, not per order. The component
cascade still reaches these, which is why remove-voided-orders needs its own
guard regardless of how complete this migration is — that was already the
recommendation and this makes it load-bearing rather than belt-and-braces.
Batch bookkeeping now records which name each charge was claimed under, so a
second order in the same batch computing that same name is left alone instead of
attempting a colliding copy.
Migration state on the restore, measured rather than asserted:
charges 17,046,418 scoped · 0 legacy · 0 unscopable
refunds 51,986 scoped · 0 legacy
payouts 144,652 scoped · 0 legacy · 36 with no owner
shifts 69,291 scoped · 0 legacy
A second full pass walked all 19M orders in 7.8 minutes and changed nothing,
which is the idempotency the tests assert, confirmed at full scale.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bryce
e05f20c135