Bot removes label

[efb4f5ff-1298-471a-8973-3d47447115dc]

Description: Bot removes label

Action version: v8

Platform:

• [ ] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [ ] Hosted
• [ ] Self-hosted

Repro steps:
In https://github.com/FreeTubeApp/FreeTube/issues/754#issuecomment-1537626941 u can see that the bot should close the issue but removed the label instead

Expected behavior: Should close the issue

Actual behavior: Removes the label preventing it from closing the issue

[dusan-trickovic]

Hello, @efb4f5ff-1298-471a-8973-3d47447115dc ! Thank you for your input, we'll take a look at the issue.

[dsame]

Hello @efb4f5ff-1298-471a-8973-3d47447115dc ,

From the URL you have sent everything looks working as expected: May 8, the issue was labeled as staled because of 28 days of inactivity - as it should be actions added the comment about the issue to be closed in 7 days May 15, the issue is closed - as it should be

Also it is not possible to reproduce the problem:

The test build runs agains the test issue and it closes it.

If you think the action does not work properly can you please provide the exact configuration of the build: its workflow YAML file and if possible - logs of the stale build with pointed

[efb4f5ff-1298-471a-8973-3d47447115dc]

I think u overlooked a few things in the issue

From the URL you have sent everything looks working as expected: May 8, the issue was labeled as staled because of 28 days of inactivity - as it should be actions added the comment about the issue to be closed in 7 days

This is true but look at the picture i added below, the label was added on 8 may but also removed by the bot on 8 may

May 15, the issue is closed - as it should be

The bot did not close the issue. I did that myself

This was the config at the time and hasnt changed since: https://github.com/FreeTubeApp/FreeTube/blob/development/.github/workflows/stale.yml

logs: https://github.com/FreeTubeApp/FreeTube/actions/runs/4910543174/job/13300466438

[dsame]

Thank you @efb4f5ff-1298-471a-8973-3d47447115dc for the config. It helps a lot to reproduce the problem but all the runs still works as expected.

Nevertheless it was discovered the issue was un-staled on the next run May 10

Please give us some more time to investigate why it could happen

[dsame]

Hello @efb4f5ff-1298-471a-8973-3d47447115dc , the only possible reason the issue to be un-staled is the false detection of update caused by the delay between creating the label and marking the issue as updated. The action has no control on infrastructure and works it out by having the tolerance of 15 secs.

It seems in the case of the issue the delay was more than 15 sec. It is not common situation and we will gather more info before taking any action.

[timhirsh]

Hi @dsame, I'm seeing this same issue fairly consistently. I'm running v8.0.0 in debug-only mode and all 12 of these "No longer stale PRs" were caused by the tolerance exceeding 15 secs (i.e. difference between the stale label event's created_at and the PR's updated_at):

Statistics:
Processed PRs: 2326
No longer stale PRs: 12
Deleted PRs labels: 12
Fetched items: 2400
Fetched items events: 33
Fetched items comments: 33
Operations performed: 102

It was as high as 49sec in some cases. Happy to provide any more details if you need any clarification. Possibly relevant: we're using a monorepo, and this has led to more exaggerated "eventual consistency" issues due to higher volumes of activity.

A few potential ideas:

• checking the last item in the PR/Issue timeline and make sure it's not a staleness labeling event
• making this tolerance configurable

Thanks!

[johnnyaug]

Experiencing this as well, is there a workaround for this?

[lucacome]

Seems like we've just run into this too, it keeps adding and deleting the stale label without actually closing the PR https://github.com/nginxinc/nginx-gateway-fabric/pull/1623#issuecomment-2028533314

[timhirsh]

Experiencing this as well, is there a workaround for this?

The workaround I've been using is to set remove-stale-when-updated to false. After the issue described here is fixed, I plan on switching back to the default true.