Symptom
The function that auto-filled required attributes was returning 400 invalid option value. The reason was simple — that attribute is of a "select" type, so it only accepts values from the allowed-value list the platform returns in its category metadata. Arbitrary strings get rejected.
So it was fixed to "take the first item from the allowed list." The 400s stopped. And adult footwear got registered with an infant size.
Cause
The first item is whatever the sort order puts there. For a size list, that was the smallest value.
★★★ Satisfying the constraint and satisfying the meaning are different problems, and only the first one was solved.
| Layer | Outcome |
|---|---|
| Outside the allowed list | 400 — a loud failure. You know at once |
| Inside the list but semantically wrong | Passes. An infant size appears on the customer's screen |
★★★ The second is the dangerous one. No error, so nobody knows, and the only paths to discovery are an order and a return. It belongs to this collection's silent failure family, and having passed the validator actively provides false reassurance.
Fix
★★ The median is chosen to "be less wrong when wrong." First and last items are the extremes of the distribution, which is exactly where infant sizes and outsized variants live. When you don't know the meaning, pick the middle, not an end.
⚠️ ★★ The median is still a guess. If the product's actual specification exists, use it — and if it doesn't, first ask whether leaving the attribute empty beats filling it wrongly. A required attribute can't be left empty, but plenty of optional ones get filled purely out of habit.
★★★ There is an option between "never leave it empty" and "put anything in" — decline to fill and hand that record to a human. Making auto-fill coverage a KPI hides that option entirely.
How to verify
★ After registration, read the value actually displayed on the public product page and compare. Not the value you sent — the value shown. This trap leaves no trace in either the request or the response.