Re: [PATCH many 00/29] notifications: add nested match expressions

[Arthur Bied-Charreton <a.bied-charreton@proxmox.com>]

On Thu, Jul 09, 2026 at 01:56:47PM +0200, Lukas Wagner wrote:
> NOTE: I have a couple of other patches planned for the notification stack (**);
> so I guess it would make sense wait a bit before applying this -- just to avoid
> too many version bumps and too much maintainer churn.
> 
> This resolves a long-standing limitation of notification matchers. Up until
> now, notification match rules could only be one level deep, so one top-level
> combinator (all/any) and an arbitrary number of match rules as direct children.
> This severely limits which kind of matching behaviors can be represented.
> 
> The notification stack was always designed with the possibility of arbitrarily
> nested match rules, however, due to limitations in our API and config formats
> (lacking support for nested data structures), this was not implemented yet.
> 
> A prior attempt to resolve the limitations imposed by the lack of nesting was
> to add 'sub-matchers', where one matcher could evaluate the result of another
> match. After some consideration, I decided not to pursue this approach further,
> due to concerns about the UX of that approach [1].
> 
> This new series chooses a different approach. Nested match rules can now be
> represented by a single matcher in the config. The lack of support for nested
> data structures in the API was circumvented by storing a serialized form of the
> 'rule tree' as a JSON blob in a single new configuration parameter
> 'expression'. If this new key is set, the old 'match-*', 'invert-match' and
> 'mode' keys are ignored; 'expression' is intended as a replacement for these
> keys. I have not yet marked the old keys as deprecated. Theoretically these can
> stay supported for now, however when editing a matcher via the UI, the old keys
> will always be translated into an equivalent 'expression'. For any new products
> receiving the notification stack, we can drop the support for the old keys by
> compiling proxmox-notify without the 'legacy-matchers' flag.
> 
> The expression evaluation logic was implemented in a new generic crate
> 'proxmox-match-expression'. 'proxmox-notify' is the first user of this crate,
> however it is generic enough to be potentially useful in other contexts as
> well.
> 
> Bumps:
>   - pve-rs needs proxmox-notify bumped
>   - pve-manager needs pve-rs and widget-toolkit bumped
>   - proxmox-backup needs widget-toolkit and proxmox-notify bumped
>   - proxmox-notify needs a first release of proxmox-match-expression
>   
>   - proxmox-mail-forward needs to be rebuilt against bumped proxmox-notify (unless
>     it has already been changed to not call into proxmox-notify anymore, see below)
> 
> [1] https://lore.proxmox.com/pbs-devel/20250521142309.264719-1-l.wagner@proxmox.com/
> 
> 
> (**): Some of the things I want to improve/implement:
>    - Migrate PVE to use a worker-based approach, same as in PBS
>      -> once that is done, we can fully migrate proxmox-mail-forward
>         to use the worker/spool dir approach, instead of using proxmox-notify
>         directly
>    - Introduce a notification history
>    - Refactor error types in proxmox-notify a bit
> 
> Also, Arthur's XOAUTH2 patch series should probably be applied in one go with
> my efforts. He probably needs to rebase on top of my changes anyway.
> 
[...]

thanks a lot for working on this! this is a  very nice improvement to 
the notification stack UX. 

i tested backwards compatibility with older configs and the migration to
the new expression format on R/W cycles, it works really well and the
generated new format is semantically equivalent fwict. old configs that
have not yet been migrated still work as expected. 

broken matcher expressions only abort evaluation for that matcher, not
for the whole notification. 

old rules are ignored if 'expression' is set, as advertised. 

i replied to some patches with some comments/questions, overall i think
this is already in great shape, nice work!!

[0] https://pve.proxmox.com/pve-docs/chapter-notifications.html#notification_matchers_calendar
[1] https://lore.proxmox.com/pve-devel/20260723114258.316106-1-a.bied-charreton@proxmox.com/T/#u
[2] https://lore.proxmox.com/pbs-devel/20260723114548.319543-1-a.bied-charreton@proxmox.com/T/#u