Skip to content
This repository has been archived by the owner on Jul 30, 2024. It is now read-only.

Update publishing guidelines #219

Closed
wants to merge 1 commit into from
Closed

Update publishing guidelines #219

wants to merge 1 commit into from

Conversation

gchudnov
Copy link
Collaborator

Update documentation for publishing failures

fixes #217

Signed-off-by: Grigorii Chudnov <[email protected]>
@github-actions
Copy link

github-actions bot commented Oct 10, 2023

Pull Request Test Coverage Report for Build 6474103429

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 74.341%

Totals Coverage Status
Change from base Build 6197376554: 0.0%
Covered Lines: 423
Relevant Lines: 569

💛 - 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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to retry the whole batch? some configurable retry strategy e.g. via the code.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


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;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Collaborator Author

@gchudnov gchudnov Oct 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@gchudnov gchudnov closed this Jul 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nakadi clients resilience to partial outage and partial success
2 participants