Skip to content

fix(symlinks): re-arm the cache TTL when the reload returns 304, release 0.43.8-dc.3 - #12

Merged
alexsavio merged 2 commits into
devfrom
fix/symlinks-cache-ttl-304
Aug 18, 2026
Merged

alexsavio merged 2 commits into
devfrom
fix/symlinks-cache-ttl-304

Conversation

@alexsavio

Copy link
Copy Markdown
Collaborator

loadSymlinksCache returned early on a 304 without setting symlinksCacheTime, so its own TTL guard never passed again and every failed lookup past the first expiry re-issued the conditional GET — on the hottest metadata path of every session and job VM, since --enable-symlinks-file is always passed.

New test TestCacheNotModifiedRearmsTTL counts backend GETs: 3 before the fix, 2 after. Full Symlinks suite: 63 passed.

loadSymlinksCache returned early on a 304 without touching
symlinksCacheTime, so the TTL guard at the top of the function never
passed again. In any directory that has a .geesefs_symlinks file, every
failed lookup past the first TTL expiry re-issued the conditional GET.

Failed lookups are the most common metadata operation on a mount (import
path search, stat probes, shell completion), and --enable-symlinks-file
is passed on every session and job VM, so this put an S3 round trip on
the hottest metadata path.

A 304 means the cached copy is current, so record the check time and let
the guard serve the next miss locally.
@alexsavio alexsavio changed the title fix(symlinks): re-arm the cache TTL when the reload returns 304 fix(symlinks): re-arm the cache TTL when the reload returns 304, release 0.43.8-dc.3 Aug 18, 2026
@alexsavio
alexsavio merged commit d8c27b2 into dev Aug 18, 2026
2 checks passed
@alexsavio
alexsavio deleted the fix/symlinks-cache-ttl-304 branch August 18, 2026 11:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant