import-guardlisted

# import-guard A bulk import feature earns trust or loses it on the file that isn't clean — the one with a stray blank row, a date in the wrong format on row 847, or a duplicate email three rows apart. The happy-path file with 500 perfect rows tells you nothing; every import feature handles that one. What breaks in production is the file that's 95% good, because that's the one real users actually upload. Two documented, well-known failure shapes recur here: a "success" result that's actually a silent partial failure (Salesforce's Bulk API treats partial success as the *normal* case — a job can report done while individual records failed, and a caller that only checks job status instead of separately fetching the failed-records list ships that gap straight through), and row-count corruption from something as mundane as a CRLF/LF mismatch shifting every row's field alignment by one, which is exactly what happened in a real reported NetBox bug where the first field of every row got silently dropped. Neither failure looks like a crash. Both look like success, which is what makes them worth a dedicated review rather than trusting "it didn't error." ## Step 1: find the failure unit — what does one bad row take down with it Locate where the import loop actually writes: one row at a time, in fixed-size chunks, or as a single all-or-nothing transaction around the whole file. Then find out what a single malformed or constraint-violating row does at that boundary: - **Whole-file tra