Fix hiding unverified assets

[jagodarybacka]

Resolves #3675

What has been done

The problem was that although we were removing custom assets correctly from the redux and marking them as removed in the databese then they were added back with next balances update.

• added removed filed to metadata type for consistency
• fixed the issue: filter out balance update against a list of removed custom assets

Testing

Try to reproduce steps from the linked issue. The item that was removed shouldn't go back anymore even after reload.

Latest build: extension-builds-3708 (as of Thu, 21 Dec 2023 09:27:55 GMT).

[Shadowfiend]

One path we might consider here is not using hideAsset for “Don't show” in the verification modal. Semantically, “removing” is not the same as “not trusting”—feels like we should keep the asset and mark it explicitly unverified (setting verified: false). That would also let us in the future show the user a warning if they tried to manually add it (e.g. “you previously marked this asset as untrusted, are you sure you want to add it?”).

EDIT to add: also, of course, it's unclear why we're showing an asset automatically/through asset discovery that was previously marked as explicitly removed...

[jagodarybacka]

Ok so the problem seems to be caused by removing assets from redux:

• user hides asset via "Don't show" button
• asset is marked removed in the indexing/customAssets database
• later there can be an update on balances that adds that hidden asset to the redux once again without checking in the database what was the status of a given asset

We need to either make sure we are not adding removed assets back to the redux or we should just include the information about the asset removed status in the redux state and filter it out in the selector. Will see what will be easier.

I see the problem with naming here - untrusted, hidden and removed are mixed up but let's fix it later

[michalinacienciala]

Unfortunately the problem still occurs:

Screen.Recording.2023-12-18.at.15.27.50.mov

Tested on extension-builds-3708 (as of Fri, 15 Dec 2023 13:31:07 GMT).

[michalinacienciala]

Unfortunately the problem still occurs:

Screen.Recording.2023-12-18.at.15.27.50.mov
Tested on extension-builds-3708 (as of Fri, 15 Dec 2023 13:31:07 GMT).

Hmm, I just noticed that the build I was testing on was built 3 days ago... Looks the artifact did not update after the recent commits... Will investigate why...

EDIT: Ok, the new artifact was produced, but the bot and Jagoda were editing the PR description at a similar time and Jagoda has overwritten the bot's change by mistake:

I will restore the bot's change and will test the PR on the latest build.

[michalinacienciala]

What is the expected behavior for a case where an asset is removed via the Don't show option and then user tries to add it back manually?

[jagodarybacka]

@michalinacienciala If I remember correctly such asset should reappear as verified

[michalinacienciala]

@michalinacienciala If I remember correctly such asset should reappear as verified

Yeah, that what I thought as well. But I hit a problem with adding a previously removed asset in this scenario:

1. Remove hidden asset (in my case it was LOOKSDROP on bnbspider.crypto). Asset removed (OK)
2. Add the removed asset. Asset added (OK)
3. Remove the asset again. Asset removed (at least that's how it looks) (OK)
4. Try adding the asset again - Taho shows that asset already exists and does not allow for adding it again. Looking on the assets list, the asset is not visible. (NOOK)

Screen.Recording.2023-12-18.at.16.55.58.mov

Btw, I also noticed that the balance of the LOOKSDROP asset is wrong (we show 80 on the asset list, but when trying to import the asset, balance is shown as 800 (which is in line with Etherscan). I will investigate that independently of this PR.

[jagodarybacka]

Interesting, seems like another bug but will see tomorrow if I can quickly solve it in one PR.

[jagodarybacka]

The problem mentioned above is different than the one we solved here (and not trivial to solve) so let's fix it in a separate PR.