-
Notifications
You must be signed in to change notification settings - Fork 66
POC - Handling API Logic for logging of UI Incidents #998
Comments
This is a duplicate of #863 |
@joshuawilson Sure Joshua. I will update you on this. We have taken this as a stretch goal. Thanks |
@arunkumars08 @joshuawilson This work was scoped for logging only the recommender UI exceptions/incidents ATM |
This type of thing should be done at a broader level. All of the UI needs it. If it is done for one, all benefit. If you don't have the time, then wait. If you do have the time then we should work through the architecture and concerns. |
@joshuawilson I was not aware that the platform team is already taking a lead on this. I totally agree to your point that the work should benefit all. @GeorgeActon @krishnapaparaju, I added the user story (as a stretch goal) #754 address logging of recommender UI incidents in the server and was scoped accordingly. But, apparently we are looking at a generic solution and that will require architectural discussions with a broader audience and @joshuawilson had already opened an issue #863 for that. I moving the user story and it's related tasks (#754, |
If you do get some bandwidth for this, ping me and we can collaborate on it. |
@joshuawilson you called this a dupe of #863. Is that still true? Can this be closed? |
Yes, it's a dup. We have Sentry.io set up and once we get the UI to start logging errors there, you can write up an issue to use it. |
Description
This sub task will store the information received from the UI layer in regards to error logging and store in some space.
Why
This could, in a way, help us identify the issues if any from the frontend that are gone unnoticed.
How
As we get the model from the UI layer, to begin with we can store that in a flat file just to track the progress and eventually move it to S3 buckets for better usage.
The text was updated successfully, but these errors were encountered: