A long email address on our signup form used to get quietly cut short and then rejected. The customer typed one thing, the form kept a shorter thing, and the rejection came after.
Two signup problems
We fixed two and confirmed both live in production.
The first was an invite. Someone who clicked a team invite they had already accepted was told the link had expired. They are now told to log in.
The second was the email field. A long address is no longer cut short and then rejected.
One limit, one ticket
While we were in there, the homepage slowness and the platform-wide 50-character email limit turned out to be separate problems. Each went onto its own ticket. Without the split, the slowness and the email limit would have stayed tangled into one fix.
Check your own forms
If you run a business with a signup, quote request or contact form, try this today:
Type in the longest email address a real customer could plausibly have, and see whether the form accepts it, rejects it, or quietly changes it.
Read your error messages as a customer would, and check that each one names the real reason.
Ask whoever built the form what the limit is on each field, and whether anything else in the system enforces a different limit for the same thing.
Before you blame a customer’s typo for a rejected email address, check whether your own form changed what they typed.
AI Skills
Use this lesson with the AI assistant you already use
A signup form quietly cut long email addresses short and then rejected them, and a platform-wide 50-character email limit sat behind the problem. Separately, team invite links told people they had expired when the invite had already been accepted.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Check Whether Your Own Form Changed What The Customer Typed Before Blaming Their Input
SOURCE: dxdev.com/blog/form-that-quietly-cut-off-your-email
WHAT HAPPENED: Long email addresses were quietly shortened on the signup form and then rejected, so customers saw a failure they had not caused. The cause was a platform-wide 50-character email limit. A second signup problem showed up on team invites. Someone who clicked an invite they had already accepted was told the link had expired, and they are now told to log in instead. The homepage slowness had looked related, but it turned out to be a separate problem. It went on its own ticket, apart from the email limit. Both signup fixes were confirmed live in production.
THE RULE: When a form rejects input, first check whether the system altered that input, and make sure each error message names the real reason. Every layer that enforces a limit on the same field should agree on that limit.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Enter the longest email address a real customer could plausibly have and confirm the form accepts it unchanged, rejects it with a clear message, and never silently truncates it.
2. For every field, list the length limit set by each layer that touches it (form, server, database) and confirm they all match.
3. Trigger each error state on purpose, such as revisiting an already accepted invite, and confirm the message states the real cause and tells the user what to do next.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
