Summary
The configured refresh interval is measured as active runtime. If the system suspends, the timer keeps its remaining duration and does not refresh immediately after resume, even if the configured interval has already elapsed in wall-clock time.
This is independent of the chosen interval. The 15-minute setting below is only the configuration under which the issue was observed.
Observed evidence
- Configured interval during this incident: 15 minutes.
- Last successful cache update: 21:01:01.
- System suspended: 21:04:55.
- System resumed: 21:25:57.
- The next nominal cycle was due at 21:16:01; 11 min 06 s remained when the system suspended.
- Expected time after resume: 21:37:03.
- Actual cache write: 21:36:59.
The approximately three-second difference confirms that the timer paused during suspend. There is no indication of an authentication, network, or interval-configuration failure.
Expected behavior
After resume, the plugin should detect that the last refresh is overdue according to the configured interval and refresh soon afterwards.
Proposed approach
Keep a lightweight local check running frequently and compare wall-clock time with fetchedAt; only run gh api after the configured interval has elapsed. This would refresh shortly after resume without increasing GitHub API requests.
Additional hardening
In sync.luau, inFlight is set before calling runAsync, but the return value is not checked if task startup is rejected. That case should be handled so future refreshes cannot remain blocked.
Summary
The configured refresh interval is measured as active runtime. If the system suspends, the timer keeps its remaining duration and does not refresh immediately after resume, even if the configured interval has already elapsed in wall-clock time.
This is independent of the chosen interval. The 15-minute setting below is only the configuration under which the issue was observed.
Observed evidence
The approximately three-second difference confirms that the timer paused during suspend. There is no indication of an authentication, network, or interval-configuration failure.
Expected behavior
After resume, the plugin should detect that the last refresh is overdue according to the configured interval and refresh soon afterwards.
Proposed approach
Keep a lightweight local check running frequently and compare wall-clock time with fetchedAt; only run gh api after the configured interval has elapsed. This would refresh shortly after resume without increasing GitHub API requests.
Additional hardening
In sync.luau, inFlight is set before calling runAsync, but the return value is not checked if task startup is rejected. That case should be handled so future refreshes cannot remain blocked.