fix(notifications): skip dispatch when no template matches #473

Merged

Claude-Run merged 1 commit from fix/PMS-701-drop-context-dump-fallback into main

2026-08-01 03:56:50 +02:00

Claude-Run commented

2026-08-01 03:48:44 +02:00

Member

The dispatcher fell back to a synthetic subject and a body built from the whole dispatch JSON whenever a rule had no template_id or the template row was missing. Those contexts carry recipient addresses, user ids and ticket content, so the fallback mailed internal identifiers and a debug string to a real recipient under a subject that read as an internal event name.

A rule with no usable template is now treated as a misconfiguration: dispatch logs a warn naming the tenant, event type, rule id/name and template id, skips the rule, and writes no notifications row, so the returned fanout count reflects the skip. With the template guaranteed present, the subject and body render straight off the template row; a template with no subject leaves the column NULL rather than inventing one.

The write path is closed too: template_id is now #[validate(required)] on UpsertNotificationRuleRequest, and create_rule/update_rule re-check it through require_template_id so non-HTTP callers get the same 422. A unit test scans src/, tests/ and crates/ for the two removed literals so the fallback cannot come back, and an integration test proves a legacy NULL-template rule dispatches nothing and that a template-less rule POST is rejected without persisting a row.

#PMS-701

The dispatcher fell back to a synthetic subject and a body built from the whole dispatch JSON whenever a rule had no `template_id` or the template row was missing. Those contexts carry recipient addresses, user ids and ticket content, so the fallback mailed internal identifiers and a debug string to a real recipient under a subject that read as an internal event name. A rule with no usable template is now treated as a misconfiguration: `dispatch` logs a warn naming the tenant, event type, rule id/name and template id, skips the rule, and writes no `notifications` row, so the returned fanout count reflects the skip. With the template guaranteed present, the subject and body render straight off the template row; a template with no subject leaves the column NULL rather than inventing one. The write path is closed too: `template_id` is now `#[validate(required)]` on `UpsertNotificationRuleRequest`, and `create_rule`/`update_rule` re-check it through `require_template_id` so non-HTTP callers get the same 422. A unit test scans `src/`, `tests/` and `crates/` for the two removed literals so the fallback cannot come back, and an integration test proves a legacy NULL-template rule dispatches nothing and that a template-less rule POST is rejected without persisting a row. #PMS-701

Claude-Run added 1 commit

2026-08-01 03:48:44 +02:00

fix(notifications): skip dispatch when no template matches

E2E / Playwright against staging (pull_request) Successful in 1m5s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 3m31s

Details

Integration / integration tests (pull_request) Successful in 7m57s

Details

Create release / Gate (release-branch merges only) (pull_request) Successful in 1s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

9e17079dfe

The dispatcher fell back to a synthetic subject and a body built from the whole dispatch JSON whenever a rule had no `template_id` or the template row was missing. Those contexts carry recipient addresses, user ids and ticket content, so the fallback mailed internal identifiers and a debug string to a real recipient under a subject that read as an internal event name.

A rule with no usable template is now treated as a misconfiguration: `dispatch` logs a warn naming the tenant, event type, rule id/name and template id, skips the rule, and writes no `notifications` row, so the returned fanout count reflects the skip. With the template guaranteed present, the subject and body render straight off the template row; a template with no subject leaves the column NULL rather than inventing one.

The write path is closed too: `template_id` is now `#[validate(required)]` on `UpsertNotificationRuleRequest`, and `create_rule`/`update_rule` re-check it through `require_template_id` so non-HTTP callers get the same 422. A unit test scans `src/`, `tests/` and `crates/` for the two removed literals so the fallback cannot come back, and an integration test proves a legacy NULL-template rule dispatches nothing and that a template-less rule POST is rejected without persisting a row.

#PMS-701