Broken decoding of Issue without a body (when its a PR)

[YarekTyshchenko]

Issues endpoints also return PRs. Body in a PR is Option, but isn't in Issue. This breaks at runtime during deserialisation.

github4s.GithubResponses$JsonParsingException: String: DownField(body)

[fedefernandez]

Good catch @YarekTyshchenko, we have two different operations for Issues and PRs. I'm wondering what will be the right behavior here. I guess the easy one is just to make optional the body in the Issue model.

[YarekTyshchenko]

Could filter out PRs from the issue endpoint, but it would cause unnecessary traffic. I'd be happy with an Optional body for now, since even in the docs they tell you to filter them yourself based on the presence of the pr urls field

[juanpedromoreno]

It seems like #236 has introduced a random test failure, which I've ignored here: https://github.com/47deg/github4s/pull/243/commits/24dd5566da0fd93fa95716889f5714ca32ca1174, as part of https://github.com/47deg/github4s/pull/243.

We might want to re-visit this issue later on.

[JesusMtnez]

I've done some debugging.

That test is failing because issue https://github.com/47deg/github4s/pull/1 has a body, and the test expects an empty body.

But if we use other issue with an empty body (that is a PR), like #154 , instead of receiving and empty body decoded to None, circe is decoding it to Some() :dizzy_face:

More debugging is needed to know why that is happening :thinking:

[YarekTyshchenko]

I've seen this before, Some PRs have empty body (from json response ""), some actual null. I can't see any regularity, but i know that once the PR is edited it will never have a null body. I can only replicate this with a private repo atm

[YarekTyshchenko]

I create my PRs with hub utility. It could be a factor

[JesusMtnez]

:thinking: Issues is implemented using circe generic auto, maybe we could implement the decoders/encoders making them handle those cases