#2927: comment id model update to long instead of int#2928
#2927: comment id model update to long instead of int#2928nickfloyd merged 8 commits intooctokit:mainfrom
Conversation
|
I think we also need to change IIssueCommentsClient and its implementation IssueCommentsClient? |
Indeed, thank you! |
|
I believe RepositoryCommentsClient & its interface should also be updated? |
Please check |
There was a problem hiding this comment.
Looks like a few comment id/number parameters were not updated to long in the other methods.
There was a problem hiding this comment.
Looks like a few comment id/number parameters were not updated to long in the other methods.
There was a problem hiding this comment.
Looks like a few comment id/number parameters were not updated to long in the other methods.
| @@ -75,7 +75,7 @@ public interface IPullRequestReviewCommentReactionsClient | |||
| /// <param name="commentId">The issue id</param> | |||
| @@ -85,6 +85,6 @@ public interface IPullRequestReviewCommentReactionsClient | |||
| /// <param name="commentId">The issue id</param> | |||
| /// <param name="owner">The owner of the repository</param> | ||
| /// <param name="name">The name of the repository</param> | ||
| /// <param name="number">The comment id</param> | ||
| /// <param name="commentId">The comment id</param> |
There was a problem hiding this comment.
Not sure if we want to rename this to commentId. Perhaps the maintainers should chime in on this one.
There was a problem hiding this comment.
It is a breaking change fix anyway. I would like to see the maintainer here to reduce the id/number confusion around the code.
There was a problem hiding this comment.
Looks like a few comment id/number parameters were not updated to long in the other methods.
There was a problem hiding this comment.
number should stay as int. The fix is about comment id only. I believe there is a huge mess around numbers/ids, and I changed it to long in all places where I think it is comment_id actually.
There was a problem hiding this comment.
Unless I am mistaken, number do not exists on comments, and only have ids which should be int64 by now. It seems number and id are used interchangeably when it comes to comments.
Take for example this method
Definition:
octokit.net/Octokit/Clients/IRepositoryCommentsClient.cs
Lines 123 to 131 in fe329e7
Implementation:
octokit.net/Octokit/Clients/RepositoryCommentsClient.cs
Lines 209 to 225 in fe329e7
The number parameter still has the type int when it should be long. The docs states that the comment_id (in this case, this parameter is called number) is of type integer which means any double without a fractional part - long should be good enough.
|
Hey y'all, First off, thank you for tackling this and thank you for moving forward on these updates to make things work/better - apologies for the trouble. This was fallout from a recent change. You are correct this issue and ones like it are why we are moving to a fully generated SDK. It looks like the tests need to be updated as well before we can ✅ and get this merged in and shipped. To answer the question regarding scope of change right now the only ID which cascades across a number of SDK APIs is Side note: The newer, generated .NET SDK has already accounted for this. That SDK gets generated nightly against the latest OpenAPI description from the GitHub REST API. |
Hey @Bazeloth While you can "approve" - because we want/need community involvement and input the merge criteria would not be met given that requires an approval from a core maintainer/owner. We do take those ☑️ checks seriously as we are going through approval though ❤️ . |
|
It looks like there's a lot more places where |
|
Take a look at https://github.com/BrianCArnold/octokit.net/tree/bugfix/%232927 Just cherry-pick that commit onto this branch if it looks good, I'm trying to get my bot working again. |
Thanks that explains a lot. I was just wondering, since in our repo people that can approve usually can merge as well. Good to see you guys took precautions 👍 |
|
... did you copy my changes into your own commit, or just do (virtually) the same thing? |
I made the changes independently and didn't see your message before doing so. |
|
Ahh, gotcha, yeah, I looked through and I see that as well. There's actually several fixes that I made that look like they got missed, let me see if I can make a patch to fix them as well. |
|
(Also, you fixed several things I missed as well) |
|
If we're doing a breaking change on this release to avoid confusions on parameter names, such as replacing " Should we include them on this PR? (https://github.com/BrianCArnold/octokit.net/tree/FixParameterNames) |
Normally I'd be a little more risk adverse, but given the scope of change here (an id field, the no longer matches the backing type + breaking change - I can definitely get behind a little bigger changeset to resolve these issues in one go. |
|
I'd like to land this as soon as possible. It looks like @arxange1 had pulled in a few changes from other sources. I'll give it another day here but after that we'll accept more PRs to address this and at least get these fixes shipped out on Monday unless anyone has any issues where this should be held up. |
Done |
|
Any ETA on the new version with this fix? |
Hey @jeny-amatya-qed I am working on a release right now... I'll let you all know when it drops. |
|
These changes have been released - https://www.nuget.org/packages/Octokit
|
|
This applies to other models as well I found today. My guess is that any See #2931 |
Old Octokit versions used int rather than long for Comment.Id; which causes overflow error when parsing responses from the GitHub Comments API. See octokit/octokit.net#2928


Resolves #2927
Before the change?
After the change?
Pull request checklist
Does this introduce a breaking change?
Please see our docs on breaking changes to help!