Fix a bug with a proven cause
Start from an observed defect. Establish its cause before making a fix, then verify the original reproduction.
Requirements
Double-clicking Submit creates two requests, especially on slow connections. The expected result is one request despite another click during submission.
Record reproduction steps and observed behavior. Keep a proposed cause as a hypothesis to verify.
Workflow
| Stage | Evidence |
|---|---|
| Reproduce | Conditions, steps and observation. |
| Investigate | A demonstrated link between code and the observed defect. |
| Approve | Human confirms sufficient evidence. |
| Fix | A scoped code change and checks. |
| Verify | Original reproduction plus neighboring behavior. |
Why prove the cause
Disabling a button may hide one path while duplicate requests still arrive another way. Inspect where the expected guarantee fails. For example, delay the response and establish which handlers run before submission state changes.
Prepare the project
- A preview with a reproducible scenario.
- A way to observe submitted requests.
- Checks for ordinary submission, repeated clicks and network errors.
- A declared scope for temporary instrumentation, when needed.
Declare debug instrumentation in the profile and remove temporary changes correctly. See the profile contract.
Rework and stops
If the cause is unproven, name the missing observation. If the fix prevents retrying after network failure, return implementation. If reproduction fails, record the conditions and request more information rather than claiming a fix.
Continue with outcomes and rework.