You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Happy to take the work to fix this, filing an issue for tracking.
Question about ergonomics, though... the current library (as well as the GitHub API spec[0]) return the thread ID as a string. Changing the library to match the spec makes it a bit more annoying to do something like 'get a thread -> call an API on that thread', since this will now require converting the returned string to an int.
Given that this 'problem' is present in the API spec, I'm inclined to match the spec, but want to double check that this is the desired behavior of this project.
OK, that's really odd. First, I would suggest contacting GitHub tech support to see if they have any recommendations.
If they don't, then I'm wondering if we should leave #3265 like you originally wrote it, using a string for the thread ID?
I opened up a case with them to see what they say. Depending on what they say, I would still lean to following their API schema, even at the expense of ease-of-use, but that's a pretty weakly held opinion, if others feel strongly.
See #3265 (comment) for context.
Happy to take the work to fix this, filing an issue for tracking.
Question about ergonomics, though... the current library (as well as the GitHub API spec[0]) return the thread ID as a string. Changing the library to match the spec makes it a bit more annoying to do something like 'get a thread -> call an API on that thread', since this will now require converting the returned string to an int.
Given that this 'problem' is present in the API spec, I'm inclined to match the spec, but want to double check that this is the desired behavior of this project.
[0] From https://docs.github.com/en/rest/activity/notifications?apiVersion=2022-11-28#get-a-thread
The text was updated successfully, but these errors were encountered: