applied: [PATCH datacenter-manager v2 1/8] api: subscription cache: ensure max_age=0 forces a fresh fetch

["Lukas Wagner" <l.wagner@proxmox.com>]

On Thu May 7, 2026 at 10:26 AM CEST, Thomas Lamprecht wrote:
> The cache lookup used 'diff > max_age', so a same-second hit with
> max_age=0 still returned cached data; collect_status_uncached and the
> direct user-supplied ?max-age=0 bypass both silently lost their
> freshness guarantee. Short-circuit max_age=0 explicitly and switch the
> TTL comparison to '>=' so the boundary is an exact miss.
>
> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> ---
>
> This threw me off quite a bit, as I observed seemingly stale cache
> issues, which where ultimately due to something completely different.
>
>  server/src/api/resources.rs | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/server/src/api/resources.rs b/server/src/api/resources.rs
> index 04628a8..50315b1 100644
> --- a/server/src/api/resources.rs
> +++ b/server/src/api/resources.rs
> @@ -830,11 +830,14 @@ fn get_cached_subscription_info(remote: &str, max_age: u64) -> Option<CachedSubs
>          .read()
>          .expect("subscription mutex poisoned");
>  
> +    if max_age == 0 {
> +        return None;
> +    }
>      if let Some(cached_subscription) = cache.get(remote) {
>          let now = proxmox_time::epoch_i64();
>          let diff = now - cached_subscription.timestamp;
>  
> -        if diff > max_age as i64 || diff < 0 {
> +        if diff >= max_age as i64 || diff < 0 {
>              // value is too old or from the future
>              None
>          } else {

applied this one already - I'm modifying the same code for my generic
cache implementation RFC, so applying this early avoids stepping on each
other's toes

Thanks!