The SKU That Pointed at the Wrong Variant After the Import

It ended at the wrong SKU. It started at the arrived. Every hand-off in between did exactly what it was told, and this is the one that lied.

Here is the shape of the import that matched on a non-unique field, and the one property that makes it silent: every row found a match, so the import reported full success, and the match was the wrong record, and the wrong record was the plausible, because the title was right and the identifier was not.

I have since met the same mechanics in plenty of data load keyed on a display field rather than an identifier.

Why the match was ambiguous

The import needed the existing product, and the existing was the lookup, and the lookup was the key, and the key was the title, and the title was the product's name, and the name was the same across the sizes, and the same was the four matches, and the four matches was the first, and the first was the arbitrary, and the arbitrary was the wrong variant, and the wrong variant was the SKU's assignment.

The identifier was the SKU, and the SKU was the unique, and the unique was the correct key, and the correct key was the not used, and the not used was the title, and the title was the convenient, and the convenient was the spreadsheet's column, and the column was the visible, and the visible was the assumption, and the assumption was the incident.

The import succeeded, and the succeeded was the every row, and the every row was the found match, and the found match was the success's signal, and the signal was the true, and the true was the misleading, because the match existed and the match was wrong, and the wrong is the ambiguity's cost.

Why the warehouse did not catch it

The pick was the SKU, and the SKU was the label, and the label was the shelf, and the shelf was the item, and the item was the physical, and the physical was the correct, and the correct was the not the ordered, and the ordered was the customer's size, and the size was the wrong, and the wrong was the shipped, and the shipped was the return.

The warehouse picked what the system said, and the system said the wrong SKU, and the wrong was the data's, and the data's was the import's, and the import's was the week, and the week was the returns, and the returns were the postage, and the postage was the margin, and the margin was the incident's cost, and the cost is the reason the import needs the verification.

This is the same key mistake as the theme update that reverted the checkout edits, same mechanism, different costume.

The fix, in order

Matched the import on the SKU. The lookup became the identifier, and the identifier was the unique, and the unique was the correct match, and the match was the fix, and the fix was the key, and the key was the one column, and the column was the discipline, because the display field is the human's key and the identifier is the machine's.

Required the unique key and failed on the duplicate. The import asserted the key's uniqueness, and the uniqueness was the guard, and the guard was the ambiguous match's block, and the block was the fix, and the fix was the check, and the check was the loud failure, and the loud was the better than the silent wrong assignment.

Imported to a draft and diffed before publishing. The draft was the staging, and the staging was the comparison, and the comparison was the changed fields, and the fields were the review, and the review was the catch, and the catch was the fix, and the fix was the gate, and the gate was the discipline, because the bulk write without the preview is the bulk mistake.

Validated the sample against the source. The sample was the ten products, and the ten were the checked by hand, and the hand was the human's eye, and the eye was the wrong variant's catch, and the catch was the fix, and the fix was the sample, and the sample was the cheap insurance, and the insurance was the discipline.

Kept the previous state for the rollback. The export before the import was the backup, and the backup was the restore, and the restore was the undo, and the undo was the fix, and the fix was the snapshot, and the snapshot was the discipline, because the bulk change without the snapshot is the one-way door.

What I now do

A bulk import must match records on a unique identifier, not on a display field, and it should fail loudly when the key is ambiguous. Match on the SKU, assert uniqueness, import to a draft and diff before publishing, check a sample by hand, and snapshot the previous state so the change can be undone.

Every product in the import found a match and every match was the wrong variant, because the import keyed on the product title and all four sizes shared one, so the SKU assignments were shuffled and the warehouse faithfully picked the wrong item a hundred times. Name that one property in review and this class of bug gets hard to ship.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud