From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id AA0CE1FF13B for ; Wed, 11 Feb 2026 13:44:21 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8B48D1BA9A; Wed, 11 Feb 2026 13:45:05 +0100 (CET) Date: Wed, 11 Feb 2026 13:44:30 +0100 From: Arthur Bied-Charreton To: Lukas Wagner Subject: Re: [PATCH pve-manager 2/5] notifications: Add refresh-targets endpoint Message-ID: <3kqo4fxy4y3lrkhv7exd57ap6llkds2sxrn7gqj6wfxbo5zrvc@pvacwvkdp3zi> References: <20260204161354.458814-1-a.bied-charreton@proxmox.com> <20260204161354.458814-11-a.bied-charreton@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1770813786086 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.879 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UVCREK3J56S2FON7LDKZ2E5ZXNTAGKPU X-Message-ID-Hash: UVCREK3J56S2FON7LDKZ2E5ZXNTAGKPU X-MailFrom: a.bied-charreton@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Feb 11, 2026 at 10:49:45AM +0100, Lukas Wagner wrote: > On Wed Feb 4, 2026 at 5:13 PM CET, Arthur Bied-Charreton wrote: > > This endpoint allows triggering a refresh of the notification targets' > > state, e.g., to prevent OAuth2 refresh tokens from expiring. > > > > Signed-off-by: Arthur Bied-Charreton > > --- > > PVE/API2/Cluster/Notifications.pm | 34 +++++++++++++++++++++++++++++++ > > 1 file changed, 34 insertions(+) > > > > diff --git a/PVE/API2/Cluster/Notifications.pm b/PVE/API2/Cluster/Notifications.pm > > index a45a15b2..f993817d 100644 > > --- a/PVE/API2/Cluster/Notifications.pm > > +++ b/PVE/API2/Cluster/Notifications.pm > > @@ -321,6 +321,40 @@ __PACKAGE__->register_method({ > > }, > > }); > > > > +__PACKAGE__->register_method({ > > + name => "refresh_targets", > > + path => 'refresh-targets', > > Same note here regarding naming, I think 'refresh-targets' is a bit too > generic for my taste. Either we fully narrow it down to > 'refresh-oauth-tokens', or make it rather general, e.g. > 'trigger-periodic-maintenance' (or something similar, you get the > general direction), covering the case that *maybe* some other endpoint > could need some periodic action as well. > You're right, the naming is kind of a WIP.. Maybe something like 'trigger-state-refresh' would make sense? 'refresh-oauth-tokens' is a bit too narrow imo, we would have to change it/add a new one again if proxmox-notify needs more state in the future > Also, do have any plans of exposing this in the GUI somehow? It's > definitely nice to have this available via pvesh for manual > troubleshooting by an admin anyways, so the API endpoint makes sense; > but as far as I can tell you do not use this endpoint anywhere in the > GUI code; hence I'm asking. > I don't mean to use it in the UI no, it is intended for pvesh