-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Reliablity Guarantees section in README #403
Conversation
README.md
Outdated
|
||
### Events are delivered _at most once_ | ||
|
||
Event Gateway tries to deliver an event only once, there is no retry mechanism. This and lack of durability implicates that event will be delivered to the subscriber _at most once_. Even though Event Gateway itself doesn't retry failed function invocations, AWS SDK used by few providers does that internally by default. The retry logic there happens only for very specific reasons and should not cause delivering the same event multiple times. Please find more information in [AWS documentation on API retries](https://docs.aws.amazon.com/general/latest/gr/api-retries.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would suggest rephrasing
"Event Gateway attempts delivery fulfillment for an event only once and consequently any event received successfully by the event gateway is guaranteed to be received by the subscriber at most once. That said, the nature of Event Gateway provider implementation could result in retries under specific circumstances, but these should not cause delivering the same event multiple times. For example, Providers for AWS Services that use the AWS SDK are subject to auto retry logic thats built into the SDK AWS documentation on API retries."
README.md
Outdated
|
||
### Events are not durable | ||
|
||
The event received by Event Gateway is stored only in memory, it's not persisted to disk during processing. This means that in case of hardware failure or software crash the event may not be delivered to the subscriber. For a synchronous subscription (`http` or `invoke` event) it can manifest by error message returned to the requester. If there is multiple subscribes to the same custom event type, in case of failure the event may not be delivered to all of them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the error code and error message returned. Are they the same under all failure conditions? Are these error codes and messages documented as such in our API documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is hardware failure or software crash nothing is returned from EG because of the obvious reason. What I meant here was that client will get some kind of error which depends on the setup e.g. for locally hosted EG it will be simple connection error, for self hosted EG behind AWS ELB there will be error from ELB etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, but we should have the codes and messages clearly documented - Is that in the API docs?
@ganeshvlrk I updated the docs with missing error codes returned by Events API. |
Codecov Report
@@ Coverage Diff @@
## master #403 +/- ##
=======================================
Coverage 61.14% 61.14%
=======================================
Files 26 26
Lines 1521 1521
=======================================
Hits 930 930
Misses 554 554
Partials 37 37 Continue to review full report at Codecov.
|
No description provided.