PATCH /issues/{issueNumber} returns "The given key 'Content-Type' was not present in the dictionary."

[hpshelton]

Select Topic Area

Bug

Body

I've been using a PowerShell script in a GitHub Action workflow to close issues programmatically for several months. Starting last week, the script's first call to add a comment to the issue succeeds, but a subsequent call using the same headers (including the Authorization header) fails to set the state of the issue to closed. Instead, Invoke-WebRequest fails with The given key 'Content-Type' was not present in the dictionary.

$headers = @{ Authorization = "***" }
foreach ($pair in ('[{...}]' | ConvertFrom-Json )) {
    $issueNumber = $pair.IssueNumber
...
    Invoke-WebRequest -Method POST -Uri "https://api.github.com/repos/hpshelton/hpshelton.github.io/issues/$issueNumber/comments" -Headers $Headers -Body $commentBody
    Invoke-WebRequest -Method PATCH -Uri "https://api.github.com/repos/hpshelton/hpshelton.github.io/issues/$issueNumber" -Headers $Headers -Body '{"state":"closed"}'
}

StatusCode        : 201
StatusDescription : Created
Content           : {"url":"https://api.github.com/repos/hpshelton/hpshelton.github.io/issues/comments/1965640492",…
RawContent        : HTTP/1.1 201 Created
                    Server: GitHub.com
                    Date: Tue, [27](https://github.com/hpshelton/hpshelton.github.io/actions/runs/8058342726/job/22011000806#step:2:28) Feb 2024 01:44:09 GMT
                    Cache-Control: max-age=60, s-maxage=60, private
                    Vary: Accept
                    Vary: Authorization
                    Vary: Cookie
                    Vary: X-GitHub-OTP
                    Vary: Accep…
Headers           : {[Server, System.String[]], [Date, System.String[]], [Cache
                    -Control, System.String[]], [Vary, System.String[]]…}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 1782
RelationLink      : {}

Invoke-WebRequest: /home/runner/work/_temp/50e5adb1-13b5-4075-9c[39](https://github.com/hpshelton/hpshelton.github.io/actions/runs/8058342726/job/22011000806#step:2:40)-8876d10073ff.ps1:18
Line |
  18 |    Invoke-WebRequest -Method PATCH -Uri "https://api.github.com/repos/ …
     |    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The given key 'Content-Type' was not present in the dictionary.
Error: Process completed with exit code 1.

I've performed the following troubleshooting:

• I've re-reviewed the API documentation and the OpenAPI specification for this endpoint and see no reason why Content-Type would be required (and note that it was not previously required as this script ran without issues in 2023).
• I see no similar reports in Discussions or StackOverflow that would point to a resolution.
• Since the same Personal Access Token is used in both calls and the previous one succeeds, I've ruled out an authentication issue or PAT expiry.
• Running the same script with a new temporary PAT with the same permissions from my local machine succeeds with 200 OK.

This leads me to believe the issue is with the GitHub Actions execution environment changing or the API specification changing without notification. Any suggestions on how to debug further?

[eerhardt]

We are running into this in the dotnet/aspnetcore repo as well. It seems like a break in github API as this same code worked 2 days ago and only started failing recently.

[michael-rabang-vc]

As a workaround you can add Content-Type to your $headers variable.

This worked for me:
$headers += @{"Content-Type"="text/json"}

[dlnash18]

It's not just limited to GitHub. I'm getting it as well in the Cisco AsyncOS API. The API call to release a message from quarantine works, but the call to delete it fails. The only difference between the two calls is the method (POST vs DELETE), and one additional property in the JSON request body for the release. This started as soon as I upgraded from .NET 7 to .NET 8. Adding a Content-Type: text/json header worked for me as well.

[isadora99]

Thanks for flagging this issue! It seems like there might be a problem with the request headers. Make sure to include the 'Content-Type' header in your PATCH request. Hope this helps!