Debug a stack trace

I have an error I do not understand yet. Do not fix it — help me find it.

Error and stack trace:
[PASTE THE FULL TRACE]

Language / runtime / framework and versions: [DETAIL]
What I was doing when it happened: [THE ACTION OR REQUEST]
Does it reproduce: [ALWAYS / SOMETIMES / ONCE]
What changed recently: [DEPLOY, DEPENDENCY BUMP, CONFIG, DATA — OR "NOTHING I KNOW OF"]
Relevant code, if I know which part is relevant: [PASTE OR WRITE "NOT SURE"]

Produce three sections.

1. WHAT THE TRACE ACTUALLY SAYS — read it line by line: which frame is my code, which is library code, and where the failure originated as opposed to where it surfaced. Name the frame that matters and say why.

2. HYPOTHESES, RANKED — at least four, most likely first. For each: the cause in one sentence, why this trace is consistent with it, the single cheapest check that would confirm or eliminate it, and what I would see if it were true. Include at least one hypothesis that is not about my code — environment, version skew, data, or concurrency.

3. WHAT THE TRACE CANNOT TELL ME — what I would need to look at to narrow this further: a log line, a value at a specific point, a second occurrence.

Do not propose a fix. If the trace has been truncated or symbols are missing, say so and say what is missing.

Paste a stack trace and ask what is wrong, and you get one confident answer. Sometimes it is right. When it is not, it is expensive in a particular way: it is plausible, so you spend forty minutes proving it wrong, and the whole time you are not looking anywhere else. The failure is not that the model guessed — it is that being asked for *a* cause makes a single guess the shape of the answer.

Asking for ranked hypotheses with a discriminating check attached to each changes what you do next. You get an ordering to work through and, more importantly, the cheapest test for each one, so eliminating a wrong hypothesis takes two minutes instead of forty. The instruction to include at least one non-code hypothesis is there because the causes people search longest for — a version mismatch between local and production, a timezone, a value that only appears in real data — are the ones nobody thinks to check while the code is on screen.

Section three is the honest part. It states what the trace does not contain, which is usually the reason you are stuck.

1. Paste the whole trace, including the parts that look like noise

   The framework frames people trim are what identify version skew and which layer the call came through. If your trace has 'caused by' or nested traces, the innermost one is usually the real event — include all of them.

2. Answer the reproduce question accurately

   'Sometimes' points at concurrency, ordering, caching, and specific data; 'always' points at logic and configuration. Those are almost disjoint hypothesis sets, so guessing here misdirects the whole ranking.

3. Say what changed, even if you are sure it is unrelated

   'Nothing changed' is nearly always false and is worth writing as the specific 'nothing I know of' — it prompts the environment and dependency hypotheses rather than suppressing them.

4. Work the checks in order and report back

   Run the cheapest check for hypothesis one and give it the result. Eliminated hypotheses sharpen the next round; starting over with the same trace produces the same list.

• When the trace has been through a log aggregatorTruncated traces and interleaved lines from concurrent requests produce hypotheses about a trace that never existed. Get the raw trace from the source first.
• For minified or stripped production stacks without source mapsFrames without real names give it nothing to reason from, and it will still produce a confident ranking. Symbolicate first or the output is fiction with structure.
• When you already know the causeThis is for the stage where you are still lost. If you know what is wrong, asking for four hypotheses just adds three wrong ones you have to read.

• CodingApolloWrite a spreadsheet formula and understand itBuilds the Excel or Sheets formula you described, explains each part, and supplies the data that makes it return the wrong answer without erroring.
• CodingApolloWrite and test a regex or SQL queryWrites the pattern or query you asked for, explains it piece by piece, and then supplies the inputs that make it silently return the wrong thing.
• CodingRagnarökReview a diff for production risksReviews a change for the failures that only appear under real traffic and real data, and separately lists which of the new behaviour has no test.
• WritingApolloRemove AI tells from a draftRewrites text that reads as machine-written, then lists the specific phrases and structures that gave it away so you stop producing them.