Passing at creation time doesn't mean passing now

Symptom

An item registered without issue is rejected with 400 on re-save.

Cause

The platform tightened required-field validation in the meantime. Existing data survives as-is, but the moment you write it again it runs through current policy.

Specific rejection conditions

• A required attribute empty, or an evasive filler like '상세설명 참조' ("see description") → rejected
• Empty string also rejected. There has to be a real value.
• Select-type fields only accept values from the allowed list
• No duplicate item names. Assign the same name in bulk and it's rejected. Uniquify with a suffix.

Fix

• Don't remove the attribute. Removing it turns into "required field missing." Replace the value, don't delete.
• Fetch allowed values from the meta endpoint and pick from there

★ Rewriting old data in bulk isn't "editing"; it's "re-registration under current rules." Forecast the pass rate accordingly.

Caution: the opposite case exists

Missing required values → "replace the value" is right, but duplicate values had to be collapsed to one, not filled. 15 of ~130 failures were this. Don't apply one remedy to every item.

Block the source or the fix reproduces the defect

While existing items were being corrected, the registration pipeline was still injecting the placeholder phrase into every required attribute. However many correction runs went out, new registrations recreated the same defect. Correcting existing items and blocking the source are separate jobs; do the second one first.

★ The same phrase is allowed in one field and rejected in another. The "see the detail page" placeholder passes in the disclosure fields and returns 400 in the attribute fields. Judge banned phrases per field.

Abbreviate the meta and the constraints vanish

The category meta gives each attribute a unit, a list of usable units, and an input type. The saved schema kept only name and required-flag. So a bare number like "30" went out without a unit and was rejected. Preserve unit and input type from the meta, combine the base unit onto bare numbers, and block units outside the usable list before the call (no list, no constraint; don't invent one).

★ The clause after "or" in the error message was the culprit. A hypothesis built on the first clause cost days. Every clause in the message is a suspect.

Why this bites non-ASCII users

"See description" fillers are a marketplace-specific idiom; on Korean platforms 상세설명 참조 was accepted for years and then blacklisted. If your market has an equivalent boilerplate phrase, expect the same policy flip, and expect it to hit only on re-write. And the flip is per field: the disclosure block still tolerates 상세페이지 참조 ("see the detail page") while the attribute block rejects it, so a banned-phrase list has to be keyed by field, not by marketplace.

---

---