nakadi
nakadi copied to clipboard
zalando
Offset checkpoint rejected due to stale stream id doesn't provide enough error information
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.
