Establish what is happening
Identify the complete source value
Choose a controlled text value near the relevant documented limit and preserve its exact content. Record expected destination behavior and any line breaks or non-Latin characters. Compare preview and final text so a shortened display is not mistaken for stored truncation, or a stored cut mistaken for harmless visual clipping.
Compare length rules by stage
Capture the preview rule, validation rule, and destination constraint for the field. Record whether each measures characters, bytes, or another defined unit. A whole-file size limit is a separate boundary and should not be used to explain why one otherwise accepted record’s text field fails during assignment.
Locate the first rejection or cut
Trace the value through parsing, normalization, validation, and persistence. Compare a shorter control and a value with a different character representation. Record the first changed text or failed check rather than increasing every limit at once and losing evidence of which stage disagreed with the intended field contract.
What to carry forward
End with the exact source value, expected limit and unit, stage-specific rules, and first divergence. State whether the issue is rejection, stored truncation, or display. The next owner should be able to investigate a specific length boundary without assuming that every long string or non-Latin value fails for the same reason.
Technical background: PostgreSQL documentation.
Keep the decision with the work.
Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.
Create an account See the product workflow