False positive suppressions should be disallowed / emit a warning #2623

Activity

1. JordonPhillips commented on Nov 14, 2025

   

   JordonPhillips

   on Nov 14, 2025

   Contributor

   More actions

   I actually looked into implementing this a while ago (sorry for not updating here). The way we implement suppressions doesn't leave room to pass along this sort of metadata, so it would require quite a bit of doing to get working. That said, I do still think it's a good idea that we should do.
2. JordonPhillips

   added

   feature-requestA feature should be added or improved.A feature should be added or improved.

   on Nov 14, 2025
3. Mihir-Rabari commented on Sep 18, 2026

   

   Mihir-Rabari

   on Sep 18, 2026

   More actions

   I'd like to pick this up. Plan: track which suppressions actually matched a validation event through the validator pipeline and emit a WARNING for the ones that silenced nothing. I'll keep the refactor contained and open a PR shortly.
4. Mihir-Rabari commented on Sep 18, 2026

   

   Mihir-Rabari

   on Sep 18, 2026

   More actions

   PR up: #3293, implementing this. Quick summary of the approach:

   • ModelBasedEventDecorator now tracks which suppressions matched while it decorates events — trait suppressions tracked per trait value (so @suppress(["A", "B"]) only warns about the value that matched nothing), metadata ones via a matched flag (thread-safe, since validators run in parallel).
   • After all validators complete (and only when the run didn't early-return on ERRORs), each suppression that matched zero events emits an UnusedSuppression WARNING naming it and carrying its source location.
   • The new warning deliberately bypasses the suppression pipeline, so a stale suppression can never silence the warning about itself — a self-referential {id: "UnusedSuppression"} entry itself becomes a warned no-op (pinned by a test).
   • smithy validate prints WARNING-level events by default, so these surface out of the box without flag changes.

   Happy to adjust any of these choices if maintainers would prefer different semantics.