memory-debugging

Debugging with hoangsa-memory

Find the origin of a bug by walking the graph backwards from the symptom. Recall locates the suspect symbol; memory_symbol_context walks its callers until you reach the real cause.

When to Use

• "Why is this function failing?"
• "Trace where this error comes from"
• "Who calls this method?"
• "This endpoint returns 500, what's upstream?"
• Any investigation that starts with a symptom and wants a root cause.

Workflow

1. resources/read hoangsa-memory://memory/LESSONS.md           → known-bug lessons first
2. memory_recall({query: "<error or symptom>"})        → find the suspect
3. memory_symbol_context({fqn: <suspect>})             → callers / callees
4. memory_impact({fqn, direction: "up"})               → full upstream
5. Read the suspect + its callers carefully
6. After the fix: memory_lesson_outcome + remember_lesson

1. Check LESSONS.md first

A past session may have hit this bug. LESSONS.md entries are keyed on trigger strings — scan for anything matching the symptom. If a lesson says "this exact error comes from X", start there.

resources/read { uri: "hoangsa-memory://memory/LESSONS.md" }

2. Recall the symptom

Feed the error message literally. Retrieval is strongest on exact tokens (function names, error strings, log lines). For example:

memory_recall { query: "connection refused retry pool exhausted" }

Include the error type, a noun from the failing operation, and any concrete identifier (module, handler, queue name).

3. Drill with symbol_context

Once recall returns a candidate FQN:

memory_symbol_context { fqn: "pool::checkout" }

Pay special attention to:

• callers — who invoked the failing path. Bugs often live in the caller's assumptions, not the callee.
• callees — what the suspect delegates to. The actual throw site may be 1–2 hops deeper.
• references — non-call uses. A misconfigured trait impl, a generic bound violation, a type that escapes.

4. Walk upstream when stuck

If context doesn't make the cause obvious, run:

memory_impact { fqn: <suspect>, direction: "up", depth: 3 }

The depth-1 callers are the contexts in which the bug manifests. Often the bug is "caller A passes a value the callee doesn't handle"; seeing all callers at once exposes the outlier.

5. Read the code

Once you have a narrow set of suspect files, use Read with line ranges from the graph results — don't load whole files. The graph already gave you path:line for every hit.

6. Reflect after the fix

When the fix lands and tests pass:

memory_lesson_outcome {
  signal: "success",
  triggers: ["<trigger of any lesson you followed>"]
}

If the bug is durable and non-obvious (not a typo), persist a lesson:

memory_remember_lesson {
  trigger: "seeing ETIMEDOUT from the pool on cold start",
  advice: "pool::checkout has a 5s dial timeout; raise it or pre-warm
           via pool::ensure_min in the init path."
}

Keep the trigger as a situation description, not a command. Lessons fire on situation match; imperatives don't match future recalls.

Anti-patterns

• Recalling the fix instead of the symptom. "Fix retry on connection failure" matches the wrong chunks. Search what you see (the error), not what you want (the fix).
• Reading whole files on a guess. The graph gives exact path:line; use it. Reading a 2000-line file to find a 5-line bug burns context.
• Fix-then-forget. If the bug was subtle and the fix was non-obvious, a lesson saves 30 minutes next time. If the bug was a typo, skip.
• Assuming the top recall hit is the bug. Top-ranked ≠ guilty. Read the top 3 chunks; the guilty one is often #2 because the retriever rewarded surface similarity over actual behaviour.

When the symptom isn't indexed

If the error message lives in a dependency (e.g. reqwest: connection refused), recall won't find it — the error text isn't in your code. Recall for the call site instead: "reqwest get client" or the wrapper function's name. The graph will lead you to the caller, which is in your code.