Diagnostics

Collect diagnostics without leaking secrets

Useful diagnostics explain a failure stage, code and time without exposing credentials or private content. EdgeORE's wallet incident demonstrated why a generic Not connected card is inadequate: it concealed whether association, authorization, parsing or a later read failed. The diagnostic branch improves that visibility. Future testing should preserve those typed results instead of replacing them with another theory about the host.

Capture a bounded attempt

Identify the APK, runtime and external dependency before starting. Save the action sequence, visible result and a relevant log window. A failure note should answer what the user did, what the app showed, what the external component returned and what remains unknown. Do not claim a root cause merely because an error resembles a known problem. A hypothesis should name the test that could confirm or reject it.

adb logcat -d -b crash > crash.txt
adb logcat -d -t 300 > recent-logcat.txt

Review these files before publication. They may contain other applications' messages, endpoint names, document paths or sensitive identifiers. A crash buffer alone may not capture a typed wallet refusal because that can be a handled error, not a crash. The app's structured error display and redacted logs are therefore important alongside AndroidRuntime output.

Preserve distinctions

A balance read failing after authorization should show Balance unavailable, not erase the account. A wallet refusal should not become a chain failure. A null signature status should not become Not sent. A malformed RPC result should not become clean Not found. Each distinction prevents a misleading recovery action. Diagnostics are part of safe behavior because users decide what to retry based on them.

UTC time helps compare events across machines, but ordering inside one process can require monotonic timing. Wall clocks can change. Network timeouts should identify their stage without dumping request bodies that contain private documents. A digest may help correlate an operation, but even digests can reveal low-entropy content. Use stable operation IDs where possible and document any public metadata included in logs.

Share the minimum useful bundle

A good bug report includes source/APK identity, device or hosted profile, Android version, wallet or node version, reproduction steps, expected behavior, actual behavior, redacted logs and screenshots. If the failure concerns a transfer, include the public signature and cluster after checking that publication is appropriate. Never include the seed, raw auth token, development private key or node pairing secret.

Keep original private logs separately if a maintainer needs an authorized secure review; publish a redacted copy with a note that redaction occurred. Do not edit signed receipts to redact sensitive bodies and still present them as verifying originals. Prefer a non-sensitive reproduction. The acceptance goal is enough information to investigate the actual failure while maintaining the same consent and secrecy boundaries the application is supposed to protect.

---

Wiki home · Qualification updates · Sources and credits