Problems since moving to v5 - action takes bot comment as a regular update

[derberg]

Your stale action configuration

Config here -> https://github.com/asyncapi/bundler/blob/master/.github/workflows/stale-issues-prs.yml

name: Manage stale issues and PRs

on:
  schedule:
  - cron: "0 0 * * *"

jobs:
  stale:
    if: startsWith(github.repository, 'asyncapi/')
    name: Mark issue or PR as stale
    runs-on: ubuntu-latest
    steps:
    - uses: actions/stale@v5.1.0
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-issue-message: |
          This issue has been automatically marked as stale because it has not had recent activity :sleeping:

          It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation. 

          There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under [open governance model](https://github.com/asyncapi/community/blob/master/CHARTER.md). 

          Let us figure out together how to push this issue forward. Connect with us through [one of many communication channels](https://github.com/asyncapi/community/issues/1) we established here.

          Thank you for your patience :heart:
        stale-pr-message: |
          This pull request has been automatically marked as stale because it has not had recent activity :sleeping:

          It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

          There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under [open governance model](https://github.com/asyncapi/community/blob/master/CHARTER.md). 

          Let us figure out together how to push this pull request forward. Connect with us through [one of many communication channels](https://github.com/asyncapi/community/issues/1) we established here.

          Thank you for your patience :heart:
        days-before-stale: 120
        days-before-close: 120
        stale-issue-label: stale
        stale-pr-label: stale
        exempt-issue-labels: keep-open
        exempt-pr-labels: keep-open
        close-issue-reason: not_planned```

Further context

One of examples is this issue -> asyncapi/bundler#34
We run stale action every day.
So one day issue got stale label and comment from bot: https://github.com/asyncapi/bundler/runs/7602251973?check_suite_focus=true
But then, next day, it was "unstaled" with https://github.com/asyncapi/bundler/runs/7622201096?check_suite_focus=true

See the logs:

Checking for comments on issue since: 2022-08-01T00:00:42Z
Comments that are not the stale comment or another bot: 0
The stale label should not be removed
Remove the stale label since the issue has been updated and the workflow should remove the stale label when updated

I can't figure why it decided all suddenly to remove stale label.

Another example, from completely different repo, but with exactly the same configuration -> asyncapi/website#659 (comment)

Issues noticed after moving from v4.0.0 to v5.1.0

[rooterkyberian]

I have a similar issue, but my scenario is somewhat niche.
Since my billing plan doesn't allow running github actions natively I run them through https://github.com/nektos/act locally.
This is where I run in exactly the same problem as OP.

Would be nice if I could ignore updated from a particular user (which I use to run this action), instead of being hardcoded.

I acknowledge this may not be the scenario which you want to optimize the tool for, but if its would be just about exposing a configuration option instead of hardcoding something in then maybe it would be worthy addition?

[ghogen]

This is a totally blocking issue for us in the docs platform. We're forced to revert to the earlier version.

[luketomlinson]

@derberg Can you try version 5.1.1 (or just @v5)? There was a bug in 5.1.0.

[luketomlinson]

@ghogen Can you confirm which version of stale you are on? v5.1.0 has this bug.

[ghogen]

@luketomlinson
We upgraded to 5.1.0 and then about a week later, upgraded to 5.1.1.
Then after reading the issue, we just recently reverted back to v4.
I'm upgrading again to 5.1.1 and we'll see if we have any further problems, thanks

[ghogen]

@luketomlinson
Looking more closely, no, there is still something not right here. Here's the log from a run we did with 5.1.1.

Line 1847 is correct - stale should not be removed
Line 1849 says the opposite, but it is not correct - the issue was not updated so it should not be removing the stale label - the only change was that the stale label was applied and the bot comment was added, so this is resetting the update clock I think

The issue is https://github.com/MicrosoftDocs/visualstudio-docs/issues/7515

[ghogen]

The test that leads to incorrect result that "Issue has been updated since it was marked stale" is the following from line 741 of index.js:

const issueHasUpdateSinceStale = new Date(issue.updated_at) > new Date(markedStaleOn);

We know the value of "markedStaleOn" as it is printed in the log 2022-07-14T00:14:00Z. The issue updated date is also printed at the top of the log screenshot 2022-07-14T00:14:01Z, and it differs by one second. The test returned "true" because the timestamp slightly differs between those two Date objects, even though they represent the same "update" (the application of the stale label).

Suggested fix: Change the test to check if the absolute value of the difference between the two Date objects is greater than 1 minute.

[luketomlinson]

Great find @ghogen! I just merged a PR to fix it. If you're so inclined, you can try pointing your action to @actions/stale@main to see if it fixes the issue.

[derberg]

@luketomlinson, when do you plan to release?

[luketomlinson]

@derberg done! https://github.com/actions/stale/releases/tag/v5.2.0 (the v5 tag is also updated, so no action needed if you are using that)

[ghogen]

We're looking at the newer activity of the bot and still seeing that the bot's own prior activity (adding comments, adding or removing labels) is still counted as activity on the issue. This is unrelated to the timestamp comparison problem, but it matches the original title of this issue. I'm using "v5" which should pick up the 5.2.0 which I think should have the update. Here's an issue that we processed through the latest version and it decides that the "last updated date" is 9/15/2022 which is when it removed the stale label. The last real update was back in March.

https://github.com/MicrosoftDocs/visualstudio-docs/issues/6077
We have two other examples all with the same problem.

[ghogen]

@luketomlinson Honestly, I don't see in the logic in processIssues where it supposedly filters out its own activity to measure the last updated date. It looks to me like it just takes "updated_at" from the GitHub API and so where is the intelligence to ignore its own activity?