Projection troubleshooting over MCP: diagnose → step → read the Apply Added in 1.10.0
Diagnose a stalled, lagging or wrong projection — locally with the JasperFx.Events projection-run CLI command, or across a CritterWatch-monitored fleet with the MCP projection tools: diagnose_projection (shards worst-first with verdict, latched error and lag), run_projection_stepper (replay the service's PRODUCTION projection code over a slice of real events and read the per-event before/after state), get_projection_apply_source (the exact Apply overload that ran on the step you flagged).
Use when asked 'why is this projection stuck', 'this read model has the wrong number', 'which event broke the projection', or 'is this projection behind'. Covers the unmeasurable-vs-zero rule (a null gap is not a caught-up shard), the truncation discipline, the chaos-poison cross-check, and the hand-off to a failing-spec-first fix. Also the two destructive clean-up tools after a version bump: eject_projection for one orphaned progression row, and eject_retired_projection_version (CritterWatch 1.1) for every row of a retired version on every database and tenant, which the console relays only for a version it has COLLAPSED (every shard orphaned for 24 hours, listed in get_projection_lag's byProjectionVersion with a collapsedAt), why an orphan alone is not proof during a blue/green rollout, why accepted:true means published and not applied, and how to verify over MCP since a refusal is not reported back to the tool caller.
Skill details
- Skill name:
wolverine-integrations-critterwatch-projection-troubleshooting - Applies to:
wolverine,marten,polecat,fisher - Tags:
observability,critterwatch,mcp,cli,projections,event-sourcing,daemon,troubleshooting,operations,agents,eject_projection,eject_retired_projection_version,orphaned-shards,retired-versions,blue-green - Added in: 1.10.0
- License: Proprietary. Copyright JasperFx Software LLC.