Skip to content
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

Some API calls that are defined as taking ints in the GitHub spec are strings in this library #3269

Open
danhcole opened this issue Sep 16, 2024 · 2 comments
Assignees

Comments

@danhcole
Copy link
Contributor

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

{
  "title": "Thread",
  "description": "Thread",
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    ...
@gmlewis
Copy link
Collaborator

gmlewis commented Sep 16, 2024

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?

@danhcole
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants