Silent truncation: when a system stores less than you sent
The call succeeds. The import reports no error. A week later a customer receives a document with a product name cut in the middle. Nothing failed, and that is the problem.
How it happens
Every stored field has a size. A database column, a position in a fixed-width file, a field in an older business application: each holds a set number of characters. When a longer value arrives, the receiving system has three options. It can refuse the whole message, refuse the record, or keep what fits and drop the rest. Many systems do the third, because it keeps the nightly import running.
Truncation rarely exists on the first day. It appears later, in one of three ways:
- The source grows. Product labels were 25 characters for years. Marketing adds the material and the standard, and they become 50.
- The target shrinks. A new version of the receiving software, or a new regulation, reduces a field from 35 to 30 characters.
- A new target joins. The same export now also feeds a carrier, a marketplace or an invoicing platform, each with its own limits.
Why nobody notices
The sender gets a success code. The receiver logs a normal import. The truncated value is still plausible text, so no screen looks broken. The people who could connect the two facts, the one who knows the limit and the one who knows the data, usually work in different companies.
How to detect it
- Write the limits down. For each field the receiver accepts: its type, whether it is required, its maximum length. This list is the contract. It is short, and it is usually nowhere.
- Check what you send against it. Before the file or the call leaves, compare each value to the contract. The CSV validator and the JSON validator do this in the browser, with the row and the field of each problem.
- Check real data, not a test file. A hand-written sample has short labels. Last month’s export has the long ones.
How to stop it for good
A one-off check finds today’s problems. Two habits prevent the next ones.
Refuse instead of truncating. Put the check between the two systems, so that a value that does not fit is refused with its reason, in the same call, before the receiver sees it. A refusal is visible; a truncation is not. A validation endpoint does exactly this.
Treat the format as something that has versions. When the receiver announces a change, compare the new contract with the current one and test recent messages against it. You learn how many would fail, and which, while there is still time to warn the sender.