47degrees/github4s

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:

params = Map("q" -> s"${encode(query, "utf-8")}+${searchParams.map(_.value).mkString("+")}")

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 ^