Reproduce a bug from a support ticket

A reproduction is the difference between a bug being fixed this week and being discussed for three. The work is mostly recovering what the customer actually did, which is rarely what they wrote.

Steps

1. Read the ticket for facts, not for the diagnosis. Pull out: the account, the approximate time, the page or endpoint, what they saw, and what they expected. Ignore their theory of the cause — it is usually the part that leads the search astray.
2. Find the real request. Search the logs or the tracing backend for that account around that time and read the actual requests and responses. This is where the description and reality part company: a different endpoint, a truncated field, a retry, a client that gave up.
3. Match it to an error. Look for a Sentry event with the same request id or account. If there is one, you have the stack trace and you are nearly done.
4. Reproduce it in a scratch environment, with their shape of data. Not their data — the shape of it: the same empty field, the same long string, the same ordering, the same permissions. Most "cannot reproduce" is a difference in state, not in steps.
5. Reduce it. Strip the case back until removing one more thing makes it pass. What is left is the bug, and it is what the ticket should say.
6. Write it down where the fix will happen: a tracker ticket with the reduced case, the original request id, and a link back to the support conversation.

Reply to the customer once

Say you have reproduced it, in their terms, and what happens next. If you could not, say exactly what you need — the one fact that would let you — rather than asking them to describe it again.

Never

• Sign in as the customer, impersonate their account, or read their data beyond the single request under investigation, unless somebody with the authority to say so has said so in writing.
• Copy personal data into the ticket or the tracker.