Repository navigation
fix(auto): a reset already passed is re-checked at cadence, not crawled - #60
Merged
Merged
Conversation
When every account read spent but one's stored reset was already behind
the clock, earliest_recovery returned None ("unprovable"), so the engine
reported all-exhausted with no earliestResetAt and slept the 300 s
no-reset fallback. That account had come back at its reset; its reading
only predated the rollover and its row was due again within a minute.
Keeping the past reset makes schedule wait the plain interval, and the
next tick's fetch lands the switch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
deathemperor
added a commit
to deathemperor/infinitus
that referenced
this pull request
Sep 24, 2026
…after a minute (deathemperor/swapd#60) (#1586) With every account at its limit and one account's stored reset already behind the clock, the daemon read that as "no provable recovery" and slept five minutes, past the moment the account came back. On 2026-09-24 every session stayed stopped at the limit from 16:00:56Z until the switch at 16:06:13Z. swapd#60 keeps the passed reset, so the next tick comes after the plain interval and the fetch lands the switch. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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.
When every account reads spent but one's stored reset is already behind the clock,
earliest_recoveryreturnedNone("unprovable"). The engine then reportedall-exhaustedwithearliestResetAt: nulland slept the 300 s no-reset fallback. That account had come back at its reset: its reading just predated the rollover, and its row was due for a refetch within a minute. Seen live on 2026-09-24. The active account hit its 5h limit at 16:00:56Z, a minute after death4's 5h reset. The daemon ignited death4, declared all-exhausted, slept five minutes and only switched at 16:06:13Z, so every session stayed stopped at the limit in between.Fix: the past reset is kept.
sleep_untilthen sits in the past,schedulefloors it at the plain interval, and the next tick's fetch shows the account back and lands the switch. A spent account with no reset at all is still unprovable and still crawls.earliestResetAtnow names the reset that passed.Test:
a_reset_already_passed_is_rechecked_at_cadence_not_crawledfails on main (earliestResetAtnull, 300 s sleep) and passes with the fix: interval sleep, thenSwitchedonto the returned account.cargo test,cargo clippy --all-targets,cargo fmt --checkall clean.Claude Opus 5.5 via Claude Code.
🤖 Generated with Claude Code