-
Notifications
You must be signed in to change notification settings - Fork 406
Fix: Increase tolerance in isDateMoreRecentThan to 30s #1310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR addresses an issue where the stale bot incorrectly un-marks issues/PRs as stale immediately after marking them stale due to timestamp comparison discrepancies between updated_at and markedStaleOn timestamps.
Key changes:
- Increases the tolerance for date comparison in
isDateMoreRecentThanfrom 15 seconds to 30 seconds - Updates associated comments to reflect the new 30-second tolerance value
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/classes/issues-processor.ts | Updates the tolerance parameter from 15 to 30 seconds when checking if an issue has been updated since being marked stale, and updates the comment to reflect the new tolerance |
| dist/index.js | Applies the same tolerance change and comment update to the compiled distribution file |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ae079e9 to
bf02ef2
Compare
|
Another example, 21 seconds:
I also verified that there are no events in between these two timestamps: https://api.github.com/repos/paperless-ngx/paperless-ngx/issues/11487/events : https://api.github.com/repos/paperless-ngx/paperless-ngx/issues/11487/timeline as well: |
|
Happy to close this in favor of #1311 depending on wishes of the maintainers. Sorry for all the noise! |

Description:
This increases the "tolerance" of checking
updated_atvs.markedStaleOnfrom 15 to 30 seconds. See linked thread but for us recently stalebot has been marking issues stale and then un-marking them because of its own actions, seemingly just because the timestamps are > 15s:Of course I do not know exactly what the ideal tolerance would be but 30 seconds seems relatively as "safe" as 15. Nor do I know the underlying reason the tolerance is no longer sufficient, perhaps there has been drift in the GH API over time.
Of course alternatively this could be made configurable, but Im not sure how widespread this really is to warrant that.
Related issue:
See #1184 (it would close this in my case but Im not 100% certain if OP there has the same exact cause).
See also:
#816
Check list:
Mark if documentation changes are required.Mark if tests were added or updated to cover the changes.