From b6232edfd55d6e7b38c72e665636debbf788d6b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Tejero=20Cantero?= Date: Fri, 14 Aug 2026 00:53:55 +0200 Subject: [PATCH] :zap: Keep the summary cache for a working day, not ten minutes The fetch the cache exists for is a file open, and expireAfterAccess of ten minutes threw the entry away between two sessions on the same file: a listing measured at 5 ms was 26 s again fifteen minutes later. An entry is a uuid and five numbers, so the window costs nothing. --- backend/src/app/rpc/commands/files_branch.clj | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/backend/src/app/rpc/commands/files_branch.clj b/backend/src/app/rpc/commands/files_branch.clj index f92f1ccd3c..9a68c4fd2e 100644 --- a/backend/src/app/rpc/commands/files_branch.clj +++ b/backend/src/app/rpc/commands/files_branch.clj @@ -452,8 +452,13 @@ `(base-snapshot-id, source-revn, branch-revn)` — exactly the inputs the computation reads. A stale key is a cache miss, and a cache miss is the old behaviour, so the cache needs no invalidation logic; `keepalive` - and `max-size` bound memory, they never decide correctness." - (ucache/create :max-size 2048 :keepalive "10m")) + and `max-size` bound memory, they never decide correctness. + + The window is a working day rather than minutes because the fetch this + exists for is a file open: an entry is a uuid and five numbers, so + keeping it costs nothing, and a shorter window pays the whole cold cost + again for a designer who comes back after lunch." + (ucache/create :max-size 8192 :keepalive "8h")) (defn- summary-cache-key [{:keys [base-snapshot-id source-revn branch-revn]}]