-
Notifications
You must be signed in to change notification settings - Fork 45
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
Make missed notification available in the GUI #242
Comments
This issue consists of two parts: 2 Visualize the notification failures of a fulfilled subscription for the user in the Eiffel Intelligence front-end GUI. |
I think this story should have highest prioritization, due today user gets no info on whats happened with his/hers subscriptions. This new feature solves that problem by informing user via GUI what happened(failed) with his/hers subscription notifications. |
I think #207 provides equal value if not even more, without access to the aggregated object, you will not know why a notification wasn't triggered in the first place. When developing systemtests, i had to watch the aggregated objects way more than missed notifications. I'm not saying missed notifications isn't needed in fact i think it's very needed in certain situations where the service is unavailable or something went wrong when sending the notification. But that's not as often as you watch the aggregated object during debugging. At the moment we don't know if these two stories will be prioritized at all so i suggest we talk more about it once we know 😃 |
Remember, that this endpoint will also change name according to the suggested new REST API in the issue: eiffel-community/eiffel-intelligence#291 |
Eiffel Intelligence maintainers discussed different design ideas regarding on how to visualize a failed notification in the GUI, and the proposal can be seen in issue #256 . In order to implement this, first we need to make changes in the back-end: eiffel-community/eiffel-intelligence#254 |
Since Issue #256 makes this issue obsolete, I will close this issue. |
Description
The end user might not have access to the database, if so they won't notice when notification fail and thus end up in missed notifications in the database. Therefore it should be possible to view missed notifications for each subscription in the user interface so that the end users can take actions upon it.
For this to be beneficial we obviously have to update the Eiffel Intelligence back-end to also store the reason for failure of a notification in the missed notification database.
Motivation
Without this, the end users won't be able to know why a subscription was not triggering a notification if they don't have access to the database, which might not always be the case. This would enhance the debugging of flows using Eiffel intelligence a lot.
Exemplification
Lets say you have a flow A -> B -> C. Each step in the flow is triggered by a REST call from Eiffel Intelligence. If the data sent in a notification to flow step B is incorrect and that REST service is responding with 400 indicating that something was wrong with the request the end user will never know, if they don't have access to the database. However, if Eiffel Intelligence stores another field in the database entry about why the notification failed, while also providing a visualization in the front-end GUI, the user will have a lot of information to figure out why something went wrong.
With this implementation we could show each missed notification for each subscription making it possible distinguish between different issues for different subscriptions for the end user. This means, in order to address this issue changes need to be made in both Eiffel Intelligence back-end and front-end.
Benefits
The end user will have better tools to debug their pipeline flows. They will be able to know why their pipeline steps was not triggered successfully. If the reason is user input in a HTTP post request notification then it is easily fixed by updating the subscription.
Possible Drawbacks
The text was updated successfully, but these errors were encountered: