-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: Error deserializing new issues #2889
Comments
I am using version 9.1.2 and I am experiencing a similar failure for newly created issues. Result in the following error and stack trace:
|
It seems ans an bug: #1979 (or very very related) For some reason many are experiencing the issue now... |
+1 we're also facing this issue. Has taken a service down. Requires a hotfix IMHO.
|
+1, I'm seeing this as well. |
We are also impacted by this. |
I don't believe this PR is the right fix. Changing the Id to long isn't going to change the underlying APIs that use this Id, which will still expect integers. It's unclear if this is somehow a problem with GitHub's issue numbering but I believe just changing things to longs might not be the right thing if the underlying API doesn't support it. |
The underlying API spec appears to indicate that it is an int64 to me: {
"title": "Issue",
"description": "Issues are a great way to keep track of tasks, enhancements, and bugs for your projects.",
"type": "object",
"properties": {
"id": {
"type": "integer",
"format": "int64"
}, |
Maybe? I'm looking at the published docs for the latest API version which say integer which could totally be wrong. Even then, the couple of PRs out there don't fix the problem. Just changing the Id to the integer in the Issue isn't enough as there are a number of other classes in Octokit which would require being changed to longs. Like the IIssuesClient which calls the update API that is documented to be an int. |
I pulled the JSON I linked before from those published docs. As to other spots in Octokit, yeah it makes sense that there may be other areas impacted. But I will say that for my specific problem this would fix it as we don't call update issue APIs. Though I understand if the desire is to do a single more complete fix. |
@brantburnett if the underlying API for integer is int64 then I stand corrected as that would be a non-issue. It doesn't change the fact that just changing Issue's ID would be enough. I am using these classes for both deserialization and modifying issues, it can't be a partial fix just for deserialization, that int->long would need to be made to every class that's using an int Issue number. It's also unclear if this is actually an issue with Octokit which needs to be fixed or if this is an issue with GitHub, itself, that needs to be fixed on their end. Being that this started happening about 24 hours ago, it seems like someone made a change to allow long Issue IDs and broke this and the fix might end up being there. shrug At this point, who can say? |
@JimSuplizio, the core issue is that Octokit uses |
I've done some research internally and both the API and underlying data store are set up to handle types bigger than a 32-bit integer, so this bug should go away as soon as we handle the behavior more gracefully on the Octokit side. |
Does Octokit.GraphQL need a corresponding change here too? octokit/octokit.graphql.net#311 |
@kfcampbell does this need a fix also, while we're at it? "long all the things" |
IssueComment Id should be long as well, because we are at 1.900.000.000 |
What happened?
I've begun noticing errors deserializing the issue ID number when receiving issue webhooks. The value appears to be an
int
in the models but it seems GitHub has finally crossed the threshold and needs along
. My internal issue ID number was2147620872
, and the log was for a comment created webhook request.Versions
1.0.0 (we haven't upgraded in a while) but bug appears to still be present in the main branch
Relevant log output
Code of Conduct
The text was updated successfully, but these errors were encountered: