feat(frontend): improves error handling for btc wallet sync

[BonomoAlessandro]

Motivation

Currently every time the request to load the BTC wallet data fails, we display an error toast. In some cases this leads to multiple error toasts being displayed if the application has been idle. To improve the user experience we want to only show the error toast if the request fails 3 times in a row. In this way, the user will not be interrupted by unnecessary error messages when everything else works as expected.

Changes

• improves error handling

[DenysKarmazynDFINITY]

I'm a bit concerned how would it look like in this case - let's imagine user has the BTC page open, and suddenly all the content is gone. Previously, the error implied that something went wrong (even though in a very unfriendly manner). But now, it will be gone without any feedback, and in the best case the data will reappear again in 30 seconds. IMO, it would be acceptable if we re-try to fetch the data instantly, without waiting for the next worker tick.

[peterpeterparker]

Randomly landing here and unsolicited feedback: besides sharing @DenysKarmazynDFINITY's concern, I'm also worried about the implementation. If any logic related to handling potential errors from queries or updates needs to be implemented, it should be placed as close as possible to where those errors can occur otherwise, there's a risk of introducing issues as the all chain of events is not asserted. Additionally, implementing an error count in the UI for a message emitted from a worker feels a bit hacky but, that's more a personal opinion.

[BonomoAlessandro]

I updated the code so that the concern raised by @DenysKarmazynDFINITY is no longer valid. The current approach is to only reset the balancesStore and btcTransactionsStore if the data fetch fails three times in a row. This ensures that the shown data do not disappear without showing an error toast.
Additionally i have just asked prodsec if this would be a valid solution.

@peterpeterparker do you think it would be better to move the "counter logic" from the worker into the scheduler?

[peterpeterparker]

would be better to move the "counter logic" from the worker into the scheduler?

I mean the logic is not in the worker. In the current proposed implementation, the counter is on the UI side, in the listener for messages.

I haven’t looked at the code, but IMO, the logic should be placed as close as possible to the source. If the error is triggered by the scheduler, then indeed yes, it should go there. Maybe it could even become a generic feature of the scheduler, notably if other features potentially require skipping a certain counts of errors, but of course, only if this pattern is actually what’s needed, and only if it’s acceptable from a security perspective.

[BonomoAlessandro]

As discussed here prod-sec allows us to do this changes.

[DenysKarmazynDFINITY]

Small comment, otherwise LGTM!