txHistorySlice - errors caught with wrong AccountId as context

[gomesalexandre]

Overview

Currently in txHistorySlice, fetch failures are caught, which we handle by marking the AccountId as degraded:

web/src/state/slices/txHistorySlice/txHistorySlice.ts

Lines 280 to 282 in 2760692

	console.error(err)
	dispatch(txHistory.actions.setAccountIdErrored(accountId))
	}

In an ideal world, this works as intended: accounts that are partially/errored are marked as degraded.

However, there is a current bug in THORChain unchained-client (related to THOR refund Txs parsing in particular): , which makes accounts with said THOR fail fetching/unchained-client parsing.

Now where things get weird is that the accountId in scope for that exception will be... a BTC AccountId (at least it is in my case).

The result of that is that Bitcoin Tx history will fail fetching, and be marked as degraded, while in fact it fetched and parsed absolutely fine.

This also does not mark the actual errored account as errored, which is wrong both for us for debugging purposes, and for users.

References and additional details

web/src/state/slices/txHistorySlice/txHistorySlice.ts

Lines 280 to 282 in 2760692

	console.error(err)
	dispatch(txHistory.actions.setAccountIdErrored(accountId))
	}

Acceptance Criteria

• Accounts marked as degraded are the ones with actual degraded Tx history
• Accounts that fetched without any issues are not marked as degraded and their Tx history is happy

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

No response

[gomesalexandre]

Quoting @kaladinlight:

ok, so there isn't an issue with the tx history fetching and marking of errored accounts. it just looks weird since it is the thorchain parser, but we are parsing thorchain actions for all chains. so in your case it was an attempt to withdraw bitcoin via a bitcoin tx which failed during parsing. so the bitcoin tx history is degraded, just due to the thorchain parsing failing on that tx

Closing for now, we could improve by throwing better errors here since the stack doesn't deserialize into an actual stack and is a good ol' string.