Creating a team involves unmarshalling a JSON response into an Organization object, which causes an error because the blog field of the Organization struct is of type string (relevant code), where the JSON contains an object in the blog field.
Note that this is specific to the JSON response from creating a team. GET /orgs/:org returns a string in the blog field as expected.
I am using the GitHub API version 3 with the Accept: application/vnd.github.v3+json header.
Example JSON response from creating a team (partially omitted for simplicity):
{
"name": "asdf",
"id": 2469095,
...
"organization": {
...
"description": "UBC software engineering club 馃殌",
"name": "UBC Launch Pad",
"company": null,
"blog": {
"scheme": null,
"user": null,
"password": null,
"host": null,
"port": null,
"path": "www.ubclaunchpad.com",
"query": null,
"fragment": null
},
"location": "Vancouver, Canada",
...
}
}
Let me confirm, are you saying the above JSON snippet is a (partially stripped) response from GitHub API when creating a team?
This... really feels like a bug on GitHub API side. I'd be very surprised if they're returning that blog object instead of a URL string on purpose...
Is there anything in the GitHub API docs suggesting this might be a valid response? If not, I think the best thing to do is contact them and find out if it's intentional or not.
(I suspect it could be a bug that happened as part of their transition to GraphQL for API v4. Just a guess.)
Yes the snippet is a response from GitHub API after creating a team. And you're right, their docs would suggest that the blog field should just be a string.
I contacted them and will update here once I get a response.
It is a bug, GH is aware, but no timeline for fixing it.
GitHub's response:
Thanks for reaching out, Jordan -- that's a bug on our end that the team is already investigating. I can't promise an ETA, but we'll followup as soon as there's any news.
Best,
Ivan
As a temporary hack to get this working, I created a fork that prevents the bug by preventing the blog field from being unmarshalled.
They never promise an ETA (which is reasonable, software is unpredictable), but I suspect it shouldn't take long for this to get fixed, given how serious the issue is and how easy the fix probably is.
I don't think we need to do anything about it on master here for now. People who are affected by this can apply the neccessary temporary workaround, as you've done in your fork.
In the rare event that it takes them a significant time to fix it, we can consider merging it into master. But hopefully it won't come to that.
This is fixed now on GitHub's end as far as I can tell.