Repository navigation
fix: count a validation ahead of the device clock as overdue - #51
Merged
Merged
Conversation
validate_token_online measured the time since the last validation as now minus validated_at. With the device clock behind that time, the result was negative, which passed both the min_interval throttle and the grace period, so the license was never re-checked until the clock caught up, online or not. A validated_at more than 5 minutes ahead of the clock now reads as the longest possible time: Moonbase is asked, and a failure to reach it is past the grace period. Up to 5 minutes is taken as ordinary skew between the device and Moonbase, so sibling instances still hit the throttle right after a check. The JUCE controller's grace checks (the license watch, a failed refresh, and a license another instance stored) use the same rule.
github-actions Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
## [4.13.4](v4.13.3...v4.13.4) (2026-11-09) ### Bug Fixes * count a validation ahead of the device clock as overdue ([#51](#51)) ([e17bc4b](e17bc4b))
|
🎉 This PR is included in version 4.13.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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
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.
validate_token_onlinemeasured the time since the last validation by the device clock, so with that clock behindvalidated_atthe age came out negative, passed both themin_intervalthrottle and the grace period, and the license was not re-checked until the clock caught up, online or not. Avalidated_atmore than 5 minutes ahead of the clock now reads as the longest possible time (Moonbase is asked, and a failure to reach it is past the grace period), while up to 5 minutes is taken as ordinary skew so sibling instances still hit the throttle right after a check. The JUCE controller's three grace checks (the license watch, a failed refresh, and a license another instance stored) now use the same rule, and the core SDK and JUCE module docs say how the clock is used. New core and JUCE tests cover a validation an hour ahead (Moonbase answering and unreachable) and 30 seconds ahead (still throttled); all but the 30-second case fail without the fix, and both suites pass on macOS, with a GCC 13 compile check on Linux.