Offset checkpoint rejected due to stale stream id doesn't provide enough error information

[dehora]

When an offset commit is sent to the server but the stream id sent with it is stale the server returns a general 422 error with no further information a client can reason about. The only way to know what's going on is to read the error text, which isn't meant for a client to process. A subscription client is left with the following options:

• propagate the error up to the application and let it guess what to do
• handle 422 as being this error ignoring other possible 422 errors
• make assumptions about the error message string

None of these are desirable. The error condition is part of the server's state machine and should have clear signalling.

As far as I can tell everyone using the subscription API is going to hit the issue of stale stream ids. It's such a frequently raised problem that in nakadi-java, this can handled by allowing the end user to configure the client to skip 422 errors and continue, see nakadi-java/117 . That at least asks the end user to be aware of the work around, but it's still a workaround.

[lmontrieux]

Jira ticket ARUHA-831