no issue created when clippy toolstate breaks

[matthiaskrgr]

#61672 broke clippy toolstate but there was no issue created automatically.

Probably linked to rls/clippy decoupling #61670

[matthiaskrgr]

@rustbot modify labels: T-dev-tools T-infra

[ehuss]

I don't think it is related to rls. clippy-driver has never opened an issue when it has broken in the past.

The logs say I/O error: HTTP Error 422: Unprocessable Entity which is GitHub's error message for "Sending invalid fields". Unfortunately the script doesn't print the response body.

I can't see anything unusual in the script to explain why it would fail only for clippy-driver. My best guess is that there is something wrong with the list of assignees. The API docs say you can assign up to 10, so the larger number shouldn't be a problem.

@kennytm I could add some more debug output to publish_toolstate.py to understand the 422 error. I could also try to run the code locally with my own github token to see what the error is, but I don't want to generate noise pinging people if it succeeds.

[kennytm]

Apparently the GitHub API docs is wrong, unassignable users are causing the 422 errors instead of being silently dropped as documented.

No issues for clippy-driver because @llogiq, @mcarton and @phansch can't be assigned.

I think rustfmt will have the same issue because @topecongiro can't be assigned.

Additionally, no issues for #62003 because the assignees array included the PR author @christianpoveda, which also can't be assigned.

[kennytm]

(Re-nominating for what to do with the assignees field. )