[PATCH 1/8] api: subscription cache: ensure max_age=0 forces a fresh fetch

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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 {
-- 
2.47.3