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

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

On Fri, Jul 24, 2026 at 08:44:54AM +0200, Arthur Bied-Charreton wrote:
> 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
forgot to remove those references after editing the message, might still
be interesting additional info regarding matcher docs updates