Log errors from the FastAuth frontend

[DavidM-D]

Currently we get really useful error messages from clients like "HTTP response not OK". This isn't super helpful and we don't really know what's causing them. Some of the error messages make it as far as far as the recovery service where we have logging, but we have trouble working out what request came from the user in question.

We need to send these errors somewhere and have a way of associating them with a user's crash.

It's been suggested (by @MaximusHaximus) that the right way would be to attach a unique ID to all logs and server requests, displaying them in any error message shown to a user.

This is a relatively large ticket so feel free to break it up a bit.

### Tasks
- [x] Discuss which service/tool we want to use to collect errors
- [ ] https://github.com/near/fast-auth-signer/issues/19
- [ ] https://github.com/near/fast-auth-signer/issues/28

[hcho112]

@DavidM-D Totally agree with this ticket. Most of the errors are surfaced through our users which is not good. Was thinking of an idea of setting up error monitoring tool like sentry or raygun to retrieve the errors. (I personally vote for sentry)

We could potentially integrate with our slack channel so that we will have the visibility around the error on near real time.

[hcho112]

@DavidM-D So this ticket is more about surfacing the error to our users? or more about making it easier for engineers to debug the issue?

[itegulov]

Just to chip in from the backend side on this, we are already using tracing so from our perspective as long as you can provide us with a unique tracing id we can easily integrate it into our logs. Will require adding a new field to all user-facing APIs, but shouldn't be a big deal. Alternatively, we could also supply it as an optional HTTP header? Let's agree on what this will look like before we roll out other breaking changes.

CC @volovyks

[DavidM-D]

So this ticket is more about surfacing the error to our users? or more about making it easier for engineers to debug the issue?

It's sort of a bit of both, we want to record errors and later we want to be able to connect user reported errors to our recorded errors.

(I personally vote for sentry)

Well then that makes sense unless @MaximusHaximus strongly objects

[hcho112]

@DavidM-D got feedback from @MaximusHaximus on this. Concluded that we want to avoid using sentry.

[DavidM-D]

What should we use then?

[MaximusHaximus]

• For failures that are coming from the FastAuth backend service, they should be logged by that service into our existing logging infrastructure. In those cases, we should print a request ID somewhere on the error the user receives that we can use to query the backend service's logs and identify what went wrong in a more verbose manner.

• For errors that are generated by services that we don’t control, we can add error tracking using Sentry to the frontend.

The main thing is that don’t want the frontend trying to track exceptions that should be generated, logged and actioned on by our backend service that we own and monitor

[DavidM-D]

OK @hcho112 are you OK with adding frontend logging using sentry for the things that aren't tracked on our backend services?

[hcho112]

@DavidM-D just to clarify, is this ticket targeted on setting sentry on existing near-discovery repo to capture error logs right now? or setting up sentry on upcoming fast-auth-signer repo? (or potentially both?)

[hcho112]

Apart from the error itself, what are the metrics that we want to capture? (eg. Account id? Email? Device? Browser? ) CC @diogoortega @DavidM-D