Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Heads up: stricter validation coming soon to the Update a release API endpoint #992
I an engineer on the API team at GitHub. A colleague and I are currently going through GitHub's REST API, tightening up validations.
We noticed that google/go-github is passing undocumented parameters to the Edit a release endpoint.
In particular, we're receiving the following parameters which the endpoint doesn't know about:
Currently the backend code is ignoring unknown parameters, but we're shortly going to change the validation to return a 422 Unprocessable Entity if an undocumented parameter is passed.
We're still discussing our timeline for this, but wanted to give you a heads up so you're not caught by surprise. If you have an ETA for the fix and an idea of how long people would typically need in order to update their dependencies, that information would be very useful for us to have.
Hi @kytrinyx... sorry for the delay, and thank you for this information!
Looking through the code, I see we use this struct heavily as a return value, but also use it as a request parameter both for
I'm thinking that the best option for fixing this would be to leave the API alone so that users of the repo can still easily get a
We could possibly get this working today and hopefully reviewed and merged by early next week, but then comes the problem of updating all the users of this repo to the latest version, which we have no control over.
As @gmlewis said, that struct is one of many that are used both for for output and input. For input, the intention is for users to only use a subset of the fields that are supported by the GitHub API (per documentation).
The good news is that users of go-github that correctly use the API aren't going to be affected. The bad news is that this API is easy to accidentally misuse.
If the GitHub API returns descriptive errors when new validation checks fail, that'll make it easier for anyone who's currently misusing the API to update it to avoid sending unsupported fields.
referenced this issue
Sep 7, 2018
Unless there are any objections, I plan on labeling this repo
Maybe the code itself should directly point to version
I think we have the following choices of what to do when a user incorrectly sets an unsupported field for
I think there is no single best solution, they all have certain advantages and disadvantages. My personal favorite is probably option 4 (it helps users by reporting incorrect API usage rather than hiding it). But I'm not opposed to option 3 either (it doesn't change current behavior, even if users are incorrectly setting unsupported fields). I'm okay with whichever decision @gmlewis makes.
(It's also worth considering the approach the library takes in many other places; is it viable to use whatever choice we go with everywhere else too?)