Receive 422 response when searching Issues
drwlrsn opened this issue · 6 comments
Hi! I am pretty new to Scala so bear with me. I can't really pinpoint what's going wrong, but hopefully I can explain it well enough.
Version
github4s: v0.26.0
What I trying to do
I am trying to use the Issue Search to find Pull Requests in a project, that are open and have a particular label. In the REPL, I've tried:
client.issues.searchIssues(
"",
List(OwnerParamInRepository("47degrees/github4s"), IssueTypePullRequest, LabelParam("bug"), IssueStateOpen))
.unsafeRunSync()
This returns response with a 422
status code:
GHResponse(Left(UnprocessableEntityError(Validation Failed, List(UnprocessableEntity(Search,q,InvalidFormatting)))),422, ...)
This results in a query string of +repo:47degrees/github4s+type:pr+label:bug+state:open
. Although it looks a bit odd works fine as an API request.
I noticed if everything except the OwnerParamInRepository
the search succeeds just fine.
Running
client.issues.searchIssues("", List(OwnerParamInRepository("47degrees/github4s"))).unsafeRunSync()
Returns a response of
github4s.GHResponse[github4s.domain.SearchIssuesResult] = GHResponse(Right(SearchIssuesResult(0,false,List())),200, ...)
Thanks for the great work!
mmh weird, is the leading +
the issue?
The leading +
seems to be just fine. The following request works fine:
https://api.github.com/search/issues?q=+repo:47degrees/github4s+type:pr+label:enhancement+state:open
Ah okay I think I have some more info. IssuesInterpreter
assembles a query here:
At this point the value of the q
has a string value of: +repo:47degrees/github4s+type:pr+state:open+label:enhancement
I setup mitmproxy
to check what the actual request looks like, and the request it intercepts looks like this:
GET https://140.82.113.6/search/issues?q=%2Brepo%3A47degrees/github4s%2Btype%3Apr%2Bstate%3Aopen%2Blabel%3Aenhancement
It seems like percent encoding the +
and :
chars is breaking the request
good catch! 👍
I believe I've found the source of the issue. Whether or not it's a bug proper in http4s remains to be seen, but it appears that http4s uses different encoder settings for query parameters VS the main URL. I've submitted this to them as the above issue (the second one, the first was a similar issue I thought was related but was a bit different), so hopefully we will hear back soon!
Fix is posted above ^