fix: move now = datetime.now() inside the lock to avoid stale timestamp#9349
Merged
RC-CHN merged 2 commits intoJul 22, 2026
Merged
Conversation
…mp in concurrent scenario When multiple coroutines wait for the same session lock, they all capture ow = datetime.now() before entering the lock. By the time a coroutine actually acquires the lock, the captured timestamp is stale — it reflects the time before the wait, not the actual acquisition time. This causes expired timestamps to not be cleaned and the rate limit window to be calculated from the wrong reference time. Moving ow = datetime.now() inside the lock ensures every coroutine uses the current time at the moment it acquires the lock, fixing the stale-timestamp bug for the stall strategy. Co-authored-by: yunyancuo <3468440670@qq.com>
Contributor
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
Contributor
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The test monkeypatches
rate_limit_stage.datetimewithFakeDateTime, which only implementsnow(); if the module ever uses otherdatetimeattributes this test will start failing in non-obvious ways—consider monkeypatching justdatetime.nowinstead of the entire symbol. - The expected
sleep_durations == pytest.approx([60.3, 60.3])is a bit opaque; consider deriving these values fromrate_limit_countandrate_limit_time(or adding a short comment) so the relationship between configuration and expected sleeps remains clear if the defaults are adjusted.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The test monkeypatches `rate_limit_stage.datetime` with `FakeDateTime`, which only implements `now()`; if the module ever uses other `datetime` attributes this test will start failing in non-obvious ways—consider monkeypatching just `datetime.now` instead of the entire symbol.
- The expected `sleep_durations == pytest.approx([60.3, 60.3])` is a bit opaque; consider deriving these values from `rate_limit_count` and `rate_limit_time` (or adding a short comment) so the relationship between configuration and expected sleeps remains clear if the defaults are adjusted.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
yunyancuo
force-pushed
the
fix/rate-limit-stale-timestamp
branch
from
July 22, 2026 07:41
3c9acde to
d33b06f
Compare
Contributor
Author
|
感谢 review!已根据反馈修改:
|
RC-CHN
approved these changes
Jul 22, 2026
BegoniaHe
pushed a commit
to Xero-Team/AstrBot
that referenced
this pull request
Jul 22, 2026
…mp (AstrBotDevs#9349) * fix: move now = datetime.now() inside the lock to avoid stale timestamp in concurrent scenario When multiple coroutines wait for the same session lock, they all capture ow = datetime.now() before entering the lock. By the time a coroutine actually acquires the lock, the captured timestamp is stale — it reflects the time before the wait, not the actual acquisition time. This causes expired timestamps to not be cleaned and the rate limit window to be calculated from the wrong reference time. Moving ow = datetime.now() inside the lock ensures every coroutine uses the current time at the moment it acquires the lock, fixing the stale-timestamp bug for the stall strategy. Co-authored-by: yunyancuo <3468440670@qq.com> * test: address review - subclass datetime, derive expected stall
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.
问题
当多个协程等待同一个会话锁时,它们都在进入锁之前就捕获了
now = datetime.now()。等到协程真正获取到锁时,捕获的时间戳已经过时了——它反映的是等待前的时间,而不是实际获取锁的时间。这会导致过期时间戳未被清理,限流窗口从错误的时间点计算。修复
将
now = datetime.now()移到async with self.locks[session_id]:块内部,确保每个协程在获取锁的那一刻才获取当前时间。测试
在
tests/test_rate_limit_stage.py中新增test_stalled_concurrent_events_use_current_time_after_lock:Fixes #9348