Update publishing guidelines #219
Conversation
Signed-off-by: Grigorii Chudnov <g.chudnov@gmail.com>
gchudnov
requested review from
mdedetrich,
itachi3 and
pascalh
as code owners
Pull Request Test Coverage Report for Build 6474103429
💛 - Coveralls |
| In this case the application can retry the whole batch or retry only failed events, depending on type of exception. | ||
| The decision is up to the application. However, it should be noted, that the application **should not retry the whole batch without a backoff strategy**, otherwise it can create problems for server, when many clients retry the same batch over and over. | ||
|
|
||
| ## Retry with Expponential Backoff |
There was a problem hiding this comment.
is there a way to retry the whole batch? some configurable retry strategy e.g. via the code.
There was a problem hiding this comment.
at the moment this feature is absent in the library,
but some internal projects have wrappers on top that implement exactly this functionality.
Obviously it can be added, just stating the current state.
|
|
||
| the publishing could either _succeed_, _partially succeed_ or _fail_. On success the publishing operation returns `Future[Unit]` that resolves to a `Unit` value. On _partial success_ or _failure_ the `Future` fails with an exception: | ||
|
|
||
| - `EventValidation(batchItemResponse: List[BatchItemResponse])` - on partial success; |
There was a problem hiding this comment.
it is not completely clear if it is for the case of 422 when event validation failed or 207 when actual publishing failed. 422 does not need a retry. is there any differentiation ?
There was a problem hiding this comment.
after checking, it seems that the current implementation has a bug that treats 422 as recoverable IF the retries are enabled (they are disabled by default)
Will make a fix.
Update documentation for publishing failures
fixes #217