sxsphinxstack

Skills / Starter / Inspect a stack trace

Starter Code skill

Inspect a stack trace

Inspect a stack trace to identify the failing path, first relevant application frame, runtime context, and next discriminating check.

Use the trace as a path to investigate, not a complete diagnosis.

When to use

  • Use for local, test, build, job, or production errors with a preserved trace.
  • Never expose secrets or personal data from arguments, paths, or logs.

Preconditions

  • Capture the full error, trace, timestamp, version, environment, request or job identifier, and triggering action.

Procedure

  1. Preserve the original trace and separate exception type, message, cause chain, and frames.
  2. Mark runtime, framework, dependency, generated, and application frames.
  3. Read from the throw site outward and identify the first relevant owned frame.
  4. Resolve symbols, source maps, versions, and line numbers against the exact artifact.
  5. Compare successful and failed context without assuming the deepest frame caused the fault.
  6. Form two or more hypotheses and name the next check that would distinguish them.
  7. Record the bounded finding and link it to a reproducible case or incident.

Failure plan

  • If symbols or source versions mismatch, stop attribution and recover the exact build mapping.

Worked example

A null error surfaces in framework code, but the first owned frame shows an optional account record passed into a formatter; a fixture check distinguishes missing data from a deploy mismatch.

Related skills

  • Inspect a request correlation id — Inspect a request correlation ID across gateway, service, queue, job, and database evidence to reconstruct one transaction.
  • Inspect a tls certificate — Inspect a TLS certificate chain, names, validity, issuer, key, usages, revocation signals, and served context.
  • Inspect a process environment — Inspect a process environment without exposing secrets, changing state, or confusing configured and inherited values.