n.siegfried
222c0b1c29
Nick's real location list hit the production import and got 'Internal Server Error' with no line number - BL-027's class again, three days after the migration outage: Postgres enforces VARCHAR lengths and refuses control bytes, SQLite shrugs at both, and the importers were only ever rehearsed on SQLite. Reproduced both hazards locally (an over-long value and a NUL byte import cleanly on SQLite; either 500s Postgres wholesale). Both importers now validate per row, before any INSERT, so every dialect answers the same way - with the line number and a reason: - locations: control characters; names over 200; codes over 60; combined paths over 200 (checked where the path exists, with read-counts taken before the loop so a mid-loop rejection is not counted twice) - materials: control characters; description/unit/code over 300/20/80 And the client stops lying about it: wp-list-import.js read every response with r.json(), so a plain-text 500 threw mid-parse and surfaced as 'Could not reach the server' while the server was answering fine. One tolerant reader (text -> parse if it parses -> keep status) now serves import, add and patch; a real error reads 'Import refused - HTTP 500'. Pins: materials_check +2 (over-long and control-byte rows reject at line, 20/20), locations_check +1 (over-long name rejects at line, 59/59). Items: CR-005, D6, BL-027 (second instance of its class; the probe-side dialect guard it proposes is still open). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>