A communityA long console log often contains follow-on errors. Preserve the complete private record, then identify the earliest relevant failure for the report you share.
Keep the triggering action attached
Start with what the user did and where the app was running. Record the target, mode and SDK identity. Capture the first relevant exception and its stack rather than taking only the last line of a noisy session. A screenshot can show the symptom, but it rarely contains enough context to reproduce it.
Flutter distinguishes framework-caught errors from errors outside its callbacks. Its error-handling documentation describes FlutterError.onError and PlatformDispatcher. That distinction helps you inspect the existing application’s reporting route; it is not a reason to install a new handler merely to make a test look clean.
Build a short chronology
- Record the last successful action.
- Perform the smallest sequence that triggers the failure.
- Identify the first relevant exception and its immediate context.
- Separate subsequent errors from the original event.
- Repeat from a clean starting state and compare the chronology.
Synthetic error timeline
00:00 Start from a fresh app session
00:04 Open the details view
00:07 Remove the selected row
00:07 First relevant exception: attach actual text and stack
00:08 Later layout errors: retained as follow-on output
Expected: selection moves to a surviving row
Observed: original action fails before later errors
Not yet established: framework / plugin / application causeShare enough, not everything
Include the action, first error, relevant stack frames and the reproduction’s environment. Remove credentials, personal data and unrelated user records. Keep redaction markers consistent so another developer can still follow which fixture and action produced each line.
Do not suppress console errors, replace an exception with an empty catch or discard a failed run when preparing evidence. If a custom reporting layer loses the original stack, investigate that layer separately. A quieter console is not proof that the failure has been fixed.
Record the triggering action → Find the first relevant error → Separate follow-on failures → Repeat and share redacted evidence.