Review console errors

[tschubotz]

Context

• We have quite some console errors.
• Some are from inside our code, some are from external code.
• Some are crashes, some are http 40X codes.
• This makes it hard for QA and any user to detect actual errors.
• In the weekly meeting on Nov 25, we discussed to first review the existing errors before asking QA to report them 1by1.

Task

• Please review existing common console errors we have and check whether they can be silenced or fixed.
• Examples:

Open question

• What about warnings?
  
  

[nicosampler]

I've been able to remove some warnings, some other seems to be related to libraries we are using.
@tschubotz @francovenica
Regarding the errors, do we have tracking of when they araise?

[tschubotz]

Regarding the errors, do we have tracking of when they araise?

@nicosampler not sure I understand your question. We have sentry, but we have no other tracking for errors.

[nicosampler]

I mean github tickets

[tschubotz]

I'm not aware of any besides #1658 . Feel free to open separate new ones.

[nicosampler]

These are the warning I think are coming from an external lib and there is nothing we can do.

[tschubotz]

"networkChanged" could perhaps come from onboard.js. https://github.com/blocknative/onboard/search?q=networkChanged

[nicosampler]

@tschubotz @francovenica as we talked about before, I could not reproduce some errors.. so if they appear again, we will create independent tickets to handle them properly.

@dasanra @fernandomg and I have been talking about the possibility to change some code response numbers in the backend in cases where no data was found (instead of 400 a 204). So the browser does not log these requests as errors.
@Uxio0 what do you think?

[nicosampler]

Note: https://stackoverflow.com/questions/12807753/http-get-with-204-no-content-is-that-normal/12808458#12808458

[Uxio0]

@Uxio0 what do you think?

Currently I think I'm returning 200 for everything (204 should be only as a response for requests modifying content). Only case you get a 404 is if you try to get a Safe that it does not exist, and I won't change that for a 200. Do you see another endpoint with this behaviour?