Conversation
Reported in #62, with a screenshot that says all of it: hellish 2.7.3 ... ✓ 2.7.3 up to date · via user binary · 50m ago 2.7.4 was out. The shell had checked 50 minutes earlier, when 2.7.3 really was the newest thing there was, and cache_is_fresh() used a flat 24 hour TTL -- so it would not look again until the next day. Every session in between reported "up to date" with total confidence, and the only way out was typing `update` by hand, which is the exact chore a background check exists to remove. The interval is now adaptive, because the two states are not the same question: already pending nothing left to learn -- the badge is on the prompt and the banner has announced it. A day is plenty. believed current the ONLY state in which a release can exist without us knowing, so the only one where asking buys anything. Fifteen minutes. That asymmetry is what keeps it cheap. The frequent interval applies only while there is genuinely something to find and stops the moment it is found, so the steady state for a machine with an update pending is one request a day, exactly as before. Two hammering guards come with it, because "check more often" must not become "check on every shell": * the attempt is recorded BEFORE the fetch. run_bg_update_check() writes `checked` only after it has actually learned something, so keying the interval off it meant a machine that could not reach the release server re-forked a check on every single startup, forever -- the one shape of this code that really would hammer. `attempted` backs off on failure too, while `checked` keeps meaning "last time we learned something", which is what the banner's "50m ago" reports. * and it is recorded by the PARENT, before the fork, so twenty terminals opened at once make one request instead of twenty. Nothing moves on the prompt's path: the check is still a detached double-fork and a dead release server still costs the shell nothing. tests/update_freshness_test.py drives real ptys against a counting local release server -- no network -- and pins the report itself (a 50-minute-old check must not block discovery), the discovering session announcing it without a restart, the badge on the next one, no re-check when an update is already known, a 10-second-old attempt still being fresh, six concurrent shells making at most two requests, a failed check recording the attempt but NOT claiming a success, and startup timing against a black-holed endpoint. 4 checks fail before this change. update_gate.c and format_record() are norm splits, not new behaviour. Verified: update_freshness 10/10, banner_update 16/16, update_badge and both update-test suites green, norm clean. Closes #62
Ships the fix for #62: a release published after the shell's last check was invisible until the next day, because the check interval was a flat 24 hours regardless of what the shell already knew. The interval is now adaptive -- a quarter of an hour while the shell believes it is current, a day once an update is known pending -- with the attempt claimed before the fork so many shells starting at once make one request, and a failed check backing off like a successful one. version.h, npm/package.json, the release notes and wiki/context.md agree; `make update-config-test` green; the binary reports 2.7.5.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ships v2.7.5, fixing the update check never noticing a release published after its last look (a flat 24h interval).
Now adaptive: 15 min while believed current, 24h once an update is known pending. Plus a failed-check backoff and single-flight claim so it cannot hammer.
Merged ahead of the full CI sweep at the maintainer's request, to get a testable binary out; the follow-up release will go through the normal all-green gate.