The GitHub search API can reply with a HTTP 422.
If this is the case, the OkHttpClient notices it, and throws an exception.
All exceptions are caught in the controller, and if the custom HTTP 422 one was the exception, it is managed and the error data is parsed out and returned.

Following the advice from Dmitry Ryadnenko, the return object has changed to contain both an error object, and a result object.

> Now, while this approach doesn’t looks particularly elegant or intuitive and produces quite a bit of boilerplate,
> I’ve found that it causes the least amount of problems. Also, it looks like this is an “official” way to do error handling in RxJava.
> I saw it recommended by RxJava maintainers in multiple discussions across Internet.

https://rongi.github.io/kotlin-blog/rxjava/rx/2017/08/01/error-handling-in-rxjava.html

Using any normal Spring exception handling is useless, as the exception handling is all caught by RxJava and does not reach any ControllerAdvice or other mechanisms.