Bot updates shouldn't count as "regular" updates

[pattacini]

Describe your issue

It seems that the updates that the stale bot applies to an issue do count as regular updates so we end up assigning and soon afterward removing the stale label, for example.

Your stale action configuration

My repository is https://github.com/robotology/icub-tech-support whose workflow is the following:

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@main
        with:
          stale-issue-message: 'This issue has been automatically marked as stale...'
          close-issue-message: 'This issue has been automatically closed...'
          days-before-stale: 60
          days-before-close: 7
          stale-issue-label: stale
          exempt-issue-labels: pinned
          operations-per-run: 200

Further context

I got my hunch by looking at what happened for example to a particular issue: see robotology/icub-tech-support#1096 (comment).

Here's below the corresponding action log:

[#1096] Issue #1096
  [#1096] Found this issue last updated at: 2021-06-13T08:05:32Z
  [#1096] The option only-labels (​https://github.com/actions/stale#only-labels​) was not specified
  [#1096] └── Continuing the process for this issue
  [#1096] Days before issue stale: 60
  [#1096] The issue is not closed nor locked. Trying to remove the close label...
  [#1096] ├── The close-issue-label (​https://github.com/actions/stale#close-issue-label​) option was not set
  [#1096] └── Skipping the removal of the close label
  [#1096] This issue has a stale label
  [#1096] The option any-of-labels (​https://github.com/actions/stale#any-of-labels​) was not specified
  [#1096] └── Continuing the process for this issue
  [#1096] This issue has no milestone
  [#1096] └── Skip the milestones checks
  [#1096] The option exempt-all-assignees (​https://github.com/actions/stale#exempt-all-assignees​) is disabled. Only some specific assignees on this issue will skip the stale process
  [#1096] ├── The option exempt-issue-assignees (​https://github.com/actions/stale#exempt-issue-assignees​) is disabled. No specific assignee can skip the stale process for this issue
  [#1096] ├── The option exempt-assignees (​https://github.com/actions/stale#exempt-assignees​) is disabled. No specific assignee can skip the stale process for this issue
  [#1096] ├── No assignee option was specified to skip the stale process for this issue
  [#1096] └── Skip the assignees checks
  [#1096] This issue is already stale
  [#1096] Checking for label on this issue
  [#1096] Issue marked stale on: 2021-06-13T08:05:32Z
  [#1096] Checking for comments on issue since: 2021-06-13T08:05:32Z
  [#1096] Comments not made by actor or another bot: 0
  [#1096] Issue has been commented on: false
  [#1096] Days before issue close: 7
  [#1096] Issue has been updated: true
  [#1096] The option remove-stale-when-updated (​https://github.com/actions/stale#remove-stale-when-updated​) is: true
  [#1096] The stale label should not be removed due to an update
  [#1096] The option remove-stale-when-commented (​https://github.com/actions/stale#remove-stale-when-commented​) is: true
  [#1096] The stale label should not be removed due to a comment
  [#1096] Remove the stale label since the issue has an update and the workflow should remove the stale label when updated
  [#1096] The issue is no longer stale. Removing the stale label...
  [#1096] Removing the label "stale" from this issue...
  [#1096] The label "stale" was removed
  [#1096] Skipping the process since the issue is now un-stale
  [#1096] 2 operations consumed for this issue

From the log, we can extract the following two relevant info:

• Found this issue last updated at: 2021-06-13T08:05:32Z
• Issue marked stale on: 2021-06-13T08:05:32Z

Clearly, the update time matches the time when the issue was marked as stale and as such the stale label gets removed.

For the time being, I'll be trying to use the param remove-stale-when-updated: false to get around this, although I think bot updates shouldn't count as regular updates.

Am I missing something?

[C0ZEN]

The point was raised here already #441 (comment), but you did good to open a dedicated issue to track this.

Yes, for the time being you can disable the option, or you can also use the stable stale action by using the last release instead of the main one.

[C0ZEN]

Since the logic is based on the updated_at field, I fear that we just can not (or not easily) ignore that the last update was made by the stale action or not.
When staling, the workflow process immediately start the closing process with "now" as an update date; its legacy and maybe it's useless honestly IDK, so we could skip this part, and maybe it will resolve the issue.
The next run, the workflow will use the stale label creation date instead, but I fear that the issue will be the same once again.
Ensuring that at least one test case reproduce this would be a good start.

@luketomlinson any suggestion would be welcome!

[C0ZEN]

@luketomlinson can you reverse it so that nobody has an issue? I know that people should not use the main branch so, but it would be better to think this through and take the time to provide a good workaround.
Thanks!

#507

[C0ZEN]

test('processing an issue unstale that should be stale should not unstale and should keep the stale label added', async () => {
  expect.assertions(3);
  const opts: IIssuesProcessorOptions = {
    ...DefaultProcessorOptions,
    daysBeforeStale: 7,
    daysBeforeClose: 7,
    staleIssueMessage: 'Message',
    staleIssueLabel: 'stale',
    removeStaleWhenUpdated: true,
    removeStaleWhenCommented: true
  };
  const now: Date = new Date();
  const updatedAt: Date = new Date(now.setDate(now.getDate() - 8));
  const createdAt: Date = new Date(now.setDate(now.getDate() - 9));
  const TestIssueList: Issue[] = [
    generateIssue(
      opts,
      1,
      'A real issue example; see https://github.com/actions/stale/issues/441#issuecomment-860820600',
      updatedAt.toDateString(),
      createdAt.toDateString(),
      false,
      [],
      false,
      false
    )
  ];
  const processor = new IssuesProcessorMock(
    opts,
    async () => 'abot',
    async p => (p === 1 ? TestIssueList : []),
    async (): Promise<IComment[]> => Promise.resolve([]),
    async () => new Date().toDateString()
  );

  // process our fake issue list
  await processor.processIssues(1);

  expect(processor.staleIssues).toHaveLength(1);
  expect(processor.addedLabelIssues).toHaveLength(1);
  expect(processor.closedIssues).toHaveLength(0);
});

[C0ZEN]

@luketomlinson thanks and sorry for the troubles.

[pattacini]

Thanks heaps @C0ZEN and @luketomlinson for dealing with this!