CritterWatch 0.8.0: projection detail "Dead Letter Events" section assumes a skip-and-dead-letter policy; misleading for stop-on-error apps

[erdtsieck]

Summary

The projection detail page has a Dead Letter Events section that reads:

Projection failures for event subscriptions are stored in Wolverine's dead letter queue. View dead letters filtered by this projection's event types. [View Related Dead Letters]

This assumes the monitored application uses a skip-and-dead-letter projection error policy (failing events are routed to Wolverine's dead-letter queue and the shard keeps going). For applications that use the stop-on-error policy instead, this section is misleading.

Context

In Marten/JasperFx the async daemon's default behavior (no Projections.Errors.SkipApplyErrors / dead-letter routing configured) is to stop the shard on an unhandled projection apply error, after retries — it does not write per-event entries to a projection dead-letter queue. Our application relies on exactly this: we stop all projections on error rather than skipping and dead-lettering individual events.

Under that policy:

• A projection failure halts the shard; there are no projection-level dead letters.
• "View Related Dead Letters" returns nothing relevant for these projections.
• The section's wording implies failures are individually recoverable via a DLQ, when in reality the shard simply stops and requires a fix + restart/rebuild.

Expected behavior

The projection detail page should reflect the application's actual projection error-handling policy:

• Only surface the Dead Letter Events section when skip-and-dead-letter (DLQ routing) is actually in use for that projection/store.
• For stop-on-error projections, either hide the section or replace it with an indication that the shard halts on error (and surface the stopping exception / how to restart/rebuild) instead of pointing at an empty DLQ.

If the policy isn't available in the telemetry today, exposing it (per projection / per store) would also help, since it drives how operators interpret a stopped shard.

Environment

• CritterWatch 0.8.0, WolverineFx 6.5.1, Marten 9.6.0, JasperFx 2.8.2, .NET 10
• Single-node host, enableClusterPartitioning: false
• Marten async daemon with default (stop-on-error) projection error handling

Related: #2 (multi-store high-water-mark issue) — different feature area but found in the same investigation.

[jeremydmiller]

Closed by JasperFx/CritterWatch#328. Full sequence:

Repo	PR	Net effect
jasperfx	#431	Added ProjectionErrorHandlingDescriptor to EventStoreUsage — released as JasperFx 2.9.2.
polecat	#179	Populated descriptor in TryCreateUsage — released as Polecat 4.4.1.
marten	#4708	Populated descriptor in TryCreateUsage — bundled into Marten 9.7.1.
CritterWatch	#326	Three-branch policy-aware UI on the projection detail page — soft-warn copy fallback for older monitored services.
CritterWatch	#327	Bumped JasperFx 2.9.2 + Polecat 4.4.1 + regen TS to light up the Polecat side.
CritterWatch	#328	Bumped Marten 9.7.1 to light up the Marten side.

Behaviour on the projection detail page going forward:

• Skip-and-DLQ apps (your old default): unchanged — original section, "View Related Dead Letters" button.
• Stop-on-error apps (your config): el-alert warning "Shard halts on apply error" + restart/rebuild guidance, no DLQ button. No more misleading affordance.
• Older monitored services that haven't bumped yet: rephrased copy that doesn't presume DLQ routing, with the affordance still available for the skip-and-DLQ case.

Thanks for the report — your description (the wording assumes a policy you're not running) was clear enough that the fix mirrored exactly what you suggested upstream-side ("surface the policy per projection / per store").