/rudder-profiles-debug

name: rudder-profiles-debug
description: Diagnoses RudderStack Profiles compile failures, run failures, and output-quality problems. Use when pb compile fails, pb run fails, identity stitching looks wrong, output quality regresses, or Profiles errors need structured recovery.
allowed-tools: "Bash(pb *), Read, Write, Edit"

RudderStack Profiles Debugging

Debug Profiles errors with a structured loop: classify, fix, validate, and stop before thrashing.

Workflow

1. **Classify the error** — Match the error output against the classification table below. 2. **Apply the smallest plausible fix** — One change, then re-validate. 3. **Re-run `pb compile`** (for compile errors) or the precise recovery command (for run failures). 4. **Escalate progressively** — If the first fix doesn't work:

• 2nd attempt: consult `search_profiles_docs()` for relevant documentation.
• 3rd attempt: read documentation examples and reference files.
• 4th attempt: **STOP** — present all findings to the user and ask for guidance.

5. Never attempt more than 4 fix cycles without user input.

Error Classification

| Error Pattern | Category | First Action | |---------------|----------|-------------| | `unmarshal`, `field not found`, parser line/col | YAML Structure | Check `references/common-yaml-mistakes.md`; inspect the referenced YAML section | | `id type X not found` | Cross-File Reference | Verify id_type names match between `pb_project.yaml` and `models/` files | | `model X not found` | Model Dependency | Run `pb show models`; check `from:` paths and model names | | `invalid identifier`, `column not found` | SQL/Warehouse | Call `describe_table()` to verify the column exists | | `does not match time regex` | CLI Usage | Use ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ` | | `schema_version not supported` | Version Mismatch | Run `pb version`; align `schema_version` with the binary, or `pb migrate auto --inplace` | | `warehouse not initialized` / `no connection` from `run_query()` | MCP Precondition | Call `initialize_warehouse_connection(<connection_name>)` **once** before any `run_query()` — a hard requirement documented in the MCP tool | | `baseline not found`, `checkpoint not found`, `material X (seq_no Y) not found` on an incremental run | Incremental State | `references/incremental-debugging.md` § Checkpoint & Baseline — distinguish mid-run crash (`--seq_no N`) from state drift (`--rebase_incremental`) | | Incremental run completes but values are subtly wrong; a `merge:` var uses a window function | Silent Incremental Corruption | `references/incremental-debugging.md` § Window Functions — the most likely cause is an unsupported window function under `merge:` | | nil-pointer / segfault during compile/run, `DeRef` in the trace | DeRef Crash | `references/incremental-debugging.md` § DeRef Crashes — usually a bad `pre_existing=true` with no baseline | | `rpc error`, `ModuleNotFoundError` | Python/RPC | **STOP** — surface the exact error to the user immediately |

Python/RPC errors are OUT OF SCOPE. Do not run `pip install`, modify venvs, or edit Python paths. Surface the exact error and escalate.

Run Recovery — `--seq_no N` vs `--rebase_incremental`

Two failure modes, two different flags. Picking wrong keeps you failing:

| Symptom | Cause | Recovery | |---------|-------|----------| | `pb run` crashed/aborted mid-sequence; a seq_no is partial | Interrupted run (network, timeout, kill) | `pb run --seq_no N` resumes from the failed sequence using the existing baseline | | Incremental output diverges from discrete; `baseline not found`; stale materials | State drifted (baseline from a stale seq_no, or a non-mergeable change snuck in) | `pb run --rebase_incremental` discards the checkpoint and rebuilds the baseline from scratch |

• Never resume a crashed run with plain `pb run` — extract the failed seq_no and use `--seq_no N`.
• Never use `--rebase_incremental` for a plain mid-run failure — you'll throw away good incremental progress.
• Use `pb compile` as the primary validation loop — fast, and catches most errors before a run.

See `references/incremental-debugging.md` for the full checkpoint/baseline triage.

Output-Quality Debugging

When the run succeeds but the data looks wrong (these are **profiles-mcp tools the agent calls**, not `pb` CLI commands):

1. Call the profiles-mcp tool `initialize_warehouse_connection(<connection_name>)` **once** this session before any `run_query()` — required, or `run_query()` fails with "warehouse not initialized". 2. Call `get_profiles_output_details()` for output metadata. 3. Run targeted SQL for health metrics (see `references/post-run-sql-queries.md`):

• Stitching ratio: raw IDs vs stitched entities.
• Over-stitching: entities absorbing too many IDs.
• Feature NULL rates: data completeness per feature.
• Run-over-run comparison: entity count drift between seq_nos.

4. Compare against prior runs when available. 5. Recommend `pb audit id_stitcher` and `pb show idstitcher-report` for deeper inspection of the identity graph.

Over-stitching remediation

When one entity absorbs an abnormal number of IDs:

• **First line of defense:** `filters:` on the offending id_type in `pb_project.yaml` (`type: exclude` with `value:` or `regex:`) to drop junk values — empty strings, `"unknown"`, `"NaN"`, default UUIDs, internal test IDs.
• **Shared identifiers** (one email/device across many users): add cardinality limits via `maximum_edges` on the id_type, defined in both directions.
• **Surgical exceptions:** an `id_stitcher_rules` rules.csv (entity, id1, id1_type, action) takes highest precedence over all filters.
• After any graph-shaping change: a full re-run is required — the identity graph rebuilds and checkpoints are invalidated.

Common YAML Mistakes (quick reference)

These cause the majority of compile failures:

| Mistake | Example | Fix | |---------|---------|-----| | Invented field names | `contracts:` instead of `contract:` | Check the a