Error Handling

[benjchristensen]

Error handling, and the many possible edge cases that can occur, needs thorough testing and review. Only superficial testing has been done on this. I'm pretty certain we have bugs in this area.

[benjchristensen]

Just remembered one of them ... pretty certain this is a problem: https://github.com/ReactiveSocket/reactivesocket-java/blob/4032fbdd60a19cf0e1b6e6ab06316b15f36f5e97/src/main/java/io/reactivesocket/ReactiveSocket.java#L358

[stevegury]

Indeed, this looks like a problem.
My next task will be to focus on testing the error handling.

[yschimke]

I think PublisherUtils.errorPayload is problematic. This is the default implementation for some RequestHandler methods until overriden. It seems to just send e.getMessage().getBytes(Charset.defaultCharset()) as a successful response.

For a String based request/response payloads, it doesn't seem clear that you can tell the difference from a legitimate response. Shouldn't these be error frames for that stream?

Are these known TODOS?

[NiteshKant]

Shouldn't these be error frames for that stream?

Certainly should be but the RequestHandler does not return Publisher<Frame> so it should just return a Publisher which emits error. This would in turn send error frames.

I do not see the use of an errorPayload method, errorFrame should be sufficient.

[NiteshKant]

0.5.x does handle errors correctly. I will close this since it is too generic an issue, will file specific issues if there are cases missing.