ci: bump lock-threads to v6 so the scheduled lock job can run

[tushardev-365]

The scheduled lock job has not locked a thread in months. Every run fails during input validation:

##[error]"github-token" length must be less than or equal to 100 characters long

The last 60 runs are all failures.

Why

lock-threads v4 validates its inputs with Joi, and the v4 schema is:

'github-token': Joi.string().trim().max(100),

The Actions token is now longer than 100 characters, so it fails that check and the step exits before doing any work. v6.0.2 raised the cap (v4, v5.0.x, v6.0.0 and v6.0.1 all still validate max(100), so v6.0.2 is the first safe pin):

'github-token': Joi.string().trim().max(1000),

Worth noting because it is the obvious first thing to try: dropping the github-token: line does not fix it on v4. action.yml declares default: '${{ github.token }}', so the runner substitutes the same token and it goes through the same validation.

I checked the five inputs this workflow passes against the v6 schema and all of them are still accepted, including the empty string for the two lock reasons:

'issue-lock-reason': Joi.string().valid('resolved', 'off-topic', 'too heated', 'spam', '').default('resolved'),

The action is pinned to the v6.0.2 commit, matching the existing pinning style.

The cron

The second line is a separate typo in the same file:

- cron: '* */12 * * *'

That is every minute of hours 0 and 12, not every 12 hours, so it schedules 120 runs a day instead of 2. It has been harmless so far only because all 120 fail immediately. Fixing the token without this would turn it into 120 real lock scans a day against the API, so the two belong together.

Changed to '0 */12 * * *'.

Testing

I have not run this against the repo, since the workflow only triggers on schedule or manual dispatch and I cannot dispatch it here. The failure message above is from run logs on master, and the two schema snippets are from the v4.0.1 and v6.0.2 tags of dessant/lock-threads. A workflow_dispatch run after merge would confirm it in one go.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 5c461f0. Configure here.}

[cursor]

Discussions locked after upgrade

Medium Severity

Bumping dessant/lock-threads from v4 to v6 picks up v5’s breaking change that processes discussions by default. This workflow only configures issues and PRs, and the repo actively uses Discussions for community feedback. Without process-only set to issues, prs, closed discussions can start getting locked, or the job can fail if the token lacks discussions: write.

 

^{Reviewed by Cursor Bugbot for commit 5c461f0. Configure here.}

[getsantry]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you add the label WIP, I will leave it alone unless WIP is removed ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀