Repository navigation
Conversation
) The idle timer kept whichever deadline was armed first. When an older project's catch-up was still running, the timer was armed for a newer project; once the catch-up settled, the older project waited for the newer deadline, holding its writer lock up to nearly twice the timeout. Every trim now re-arms the timer for the oldest releasable project.
This branch has not been deployed
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.
Follow-up to #2283 (#2087).
scheduleIdleReleasereturns early when a timer is already armed. The timer is armed for the oldest project a trim can release, and a project whose catch-up is still running is skipped. That leaves one ordering where the deadline is wrong:scheduleIdleRelease, which keeps B's timer.A then stays open, writer lock included, until B's deadline, which is up to nearly twice the timeout. With the 10-minute default, a project last used at 0:00 whose catch-up settles at 9:50, while another project was used at 8:20, is released at 18:20 instead of 10:00.
The fix: a trim that gets as far as scheduling now replaces the timer instead of keeping it. Trims skip scheduling while calls are in flight, and the last call to finish trims again, so a settled catch-up still gets its own deadline. There is still one timer and no polling.
Test
__tests__/mcp-idle-release-order.test.tsdrives that ordering throughexecute(). It uses fake timers and a stubProjectLifecyclethat holds A's catch-up until the test releases it. Without the fix nothing has been released at 3.6 s ([]); with it, A is released at 3.5 s and B at 4.5 s.Changelog
No new entry. #2087 is still under
[Unreleased], so no released version has this bug, and its entry already describes the intended behavior.Checks
tscclean.mcp-idle-release-orderandmcp-projectpath-lifecyclepass (24 tests).