memtrace-incident-investigation

Overview

Root cause investigation workflow for incidents, regressions, and production issues. Uses get_evolution to list changes near the incident time, then traces blast radius and execution flows to identify the likely cause.

Steps

1. Establish the timeline

Determine:

• Incident time — when did the problem start? (This becomes the to parameter)
• Lookback window — how far back to search? Start with 24 hours, expand if needed.
• Repo(s) — which services are affected? Call list_indexed_repositories to get repo_ids.

2. List changes near the incident

Call get_evolution:

{
  "repo_id": "<affected-repo>",
  "from": "<incident_time minus lookback, e.g. 24h before>",
  "to": "<incident_time ISO-8601>",
  "mode": "recent",
  "limit": 100
}

Why recent mode? Returns a chronological per-episode changelog. Focus on episodes whose reference_time is closest to the incident — especially those with high nodes_added + nodes_removed or that touch files in the failure area.

Paginate with cursor if next_cursor is present in the response.

Success criteria: A list of episodes in the window, with touched files and change counts for each.

3. Identify hotspot files and symbols

Call get_evolution again on the same window with mode: "compound":

{
  "repo_id": "<affected-repo>",
  "from": "<same as step 2>",
  "to": "<same as step 2>",
  "mode": "compound"
}

Review top_changed_files and top_touched_symbols. Cross-reference with the failure area (endpoint, module, error stack).

Decision: Prioritize symbols/files that appear in both the recent episode list (step 2) and the compound hotspots (step 3).

4. Check for unexpected changes to stable code

For hotspot symbols from step 3, resolve each with find_symbol:

{ "repo_id": "<affected-repo>", "name": "<symbol>", "limit": 10 }

Then call get_timeline — stable code that suddenly changed is suspect:

{ "repo_id": "<affected-repo>", "scope_path": "<from find_symbol>", "file_path": "<from find_symbol>" }

5. Assess the blast radius

For the top 3–5 symbols, call get_impact:

{ "repo_id": "<affected-repo>", "target": "<symbol>", "direction": "upstream" }

• How many downstream consumers were affected?
• What execution flows pass through this symbol?

Decision: Prioritize symbols where the blast radius overlaps with the reported failure area.

6. Trace execution flows

Use get_symbol_context on the top suspects to see which processes (HTTP handlers, background jobs, etc.) they participate in.

Decision: If the incident is in a specific endpoint/flow, focus on suspects that are members of that process.

7. Build the full timeline for the suspect

Once you have a primary suspect, call get_timeline with repo_id, scope_path, and file_path:

• What changed in each episode?
• When was the last "stable" version?
• Was the change a modification, or was it newly added?

8. Correlate adds vs removes per episode

From the step 2 recent response, inspect each episode's nodes_added and nodes_removed:

• High nodes_added — new code introduced (potential new bugs)
• High nodes_removed — deleted code (potential missing functionality)
• Both moderate — changed behaviour (potential regressions)

9. Check historical coupling (cochange)

For the primary suspect, call get_cochange_context:

{ "repo_id": "<affected-repo>", "target": "<symbol>", "limit": 10 }

• Which symbols historically co-change with this one?
• If the blast radius from get_impact doesn't explain the failure area, check cochange partners — the coupling may be behavioral, not structural.

Decision: If a cochange partner is in the failure area but has no direct call relationship to the suspect, it's a hidden dependency — investigate both.

10. Replay the sub-commit implementation history (if needed)

If the suspect's episode isn't clear, call get_episode_replay:

{
  "repo_id": "<affected-repo>",
  "episode_index": 0,
  "symbol": "<suspect>",
  "mode": "graph_summary"
}

• Look for attempted_and_reverted hints — approaches tried and rolled back within the episode often explain why the committed state looks the way it does.

Report: Root Cause Analysis

1. Incident Timeline — when it started, what was observed
2. Most Likely Cause — episodes and symbols closest to the incident with blast radius confirmation
3. Supporting Evidence — timeline sparsity (stable code suddenly changed?), blast radius overlap, process membership overlap
4. Change History — full timeline of the suspect symbol
5. Affected Scope — all processes and downstream consumers impacted
6. Remediation — revert the change, fix forward, or mitigate

Tool selection guide for incidents

Full parameter spec for every Memtrace tool: references/mcp-parameters.md (bundled at the memtrace-skills plugin root).

Output

The deliverable is the RCA report above. Abridged example (3 of 6 sections filled):

• Most Likely Cause — episode 2026-07-01T14:22Z modified AuthService::validateToken; upstream blast radius reaches the failing /api/login process
• Supporting Evidence — symbol was stable for 90 days before this episode; cochange partner token_cache.rs changed in the same window despite no call edge
• Remediation — revert the episode, or fix forward with an expiry guard

Common mistakes