Stack Traces SDK Users Can Act On

A twenty-frame trace that starts inside your retry helper teaches nothing. Put the error code and message first, then the first frame that is outside your package, then offer the rest behind --verbose.

Source maps and sourcemaps in release builds matter. A minified one-line stack is how you waste the only report you will get.

Frame locals and closure values hold tokens, emails, and request bodies. A trace with variables inlined is a secret-sharing feature. Ship frames and function names. Leave values out unless they are on an allow-list.

The same rule applies to the probe. You want the stack to group similar failures. You do not want a second copy of production secrets in an inbox.

After the frames, print one suggestion: the flag, the login command, or the doc URL for that code. Developers stop reading a trace at the first unfamiliar path. The suggestion has to be where their eyes already are.

If you cannot suggest a fix, say what you need next. 'Re-run with --verbose and keep this code' is a better last line than silence.

The developer sees the short form. The probe stores the code, the top frames, and their sentence. When you draft the issue, include the short form in the body so a reviewer recognizes it without a verbose log.

If the top frame is always inside your SDK, the bug is yours. If it is always in their call, the docs for that method are wrong. The inbox should make that split obvious.