mirror of
https://github.com/patriceckhart/zot.git
synced 2026-06-27 13:56:33 +02:00
916a6f71d1
CheckForUpdate used to trust any cache entry less than 12h old whose CurrentAt matched the running binary. Problem: if a user installs v0.0.72 at 16:05 (cache: up-to-date) and a v0.0.73 release ships at 18:27, relaunching zot at 18:29 hits the fresh cache and never calls the github api \u2014 the update banner stays hidden until either 12h pass or the binary is rebuilt. Noticed in the wild: v0.0.73 latest, zot 0.0.72 running, no banner. Refined logic: only short-circuit on a cached entry when it already reports Available=true. If the cache says "up to date" we let the flow fall through to fetchLatestRelease and reconcile. The api call is a single ~4s timeout request; cheap enough to do on every up-to-date launch, and the common "cache already shows available" path still skips the network entirely. Also: manually cleared /Users/pat/Library/Application Support/zot/update-check.json on my local box so the next launch sees the new v0.0.73 release without waiting; that's user state, not something to commit. |
||
|---|---|---|
| .. | ||
| extensions | ||
| modes | ||
| tools | ||
| args.go | ||
| botcmd.go | ||
| botcmd_unix.go | ||
| botcmd_windows.go | ||
| build.go | ||
| changelog.go | ||
| cli.go | ||
| config.go | ||
| extcmd.go | ||
| modelsync.go | ||
| rpc.go | ||
| systemprompt.go | ||
| update.go | ||