M6 [P1]: Filter-rule load must not silently drop unparseable rules #247
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: KofTwentyTwo/nuncio#247
Reference in new issue
Block a user
list_filter_rules(db.rs:1566-1578) silently drops rows that fail to re-parse — a rule can vanish from enforcement with no error/log. Alsomain.rs:40loads the initial rule set vialist_filter_rules().await.unwrap_or_default(), swallowing a boot-time DB error into an empty rule set (all filtering silently off). Goal: surface (error or at minimum WARN-log with the rule id) an unparseable rule rather than dropping it silently; do not swallow the boot-time load error into an empty set. Tests for both.Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.
Delivered via PR #269 (squash-merged to dev). list_filter_rules now WARN-logs an unparseable rule row (with its id) and skips it instead of dropping it invisibly (skip-with-WARN keeps one corrupt row from disabling all enforcement while making the loss operator-visible). Boot-time load (new load_initial_filter_rules helper) now propagates a genuine DB error (main .await?) instead of unwrap_or_default-ing to an empty rule set, while still returning Ok(empty) for a healthy empty DB. Tests: WARN-capture, error-propagation (pool-closed), healthy-empty.