feat(network)_: implement deactivatable networks #6315
Conversation
Jenkins BuildsClick to see older builds (106)
|
dlipicar
changed the title
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
2 times, most recently
from
be87d05 to
2f4a1d5
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #6315 +/- ##
===========================================
+ Coverage 60.38% 60.41% +0.02%
===========================================
Files 845 846 +1
Lines 111362 111477 +115
===========================================
+ Hits 67249 67349 +100
- Misses 36308 36310 +2
- Partials 7805 7818 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
|
dlipicar
force-pushed
the
fix/migration-check-script
branch
from
7c849a8 to
d7d7aa8
Compare
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
2 times, most recently
from
ae1544a to
2ee1371
Compare
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
from
2ee1371 to
e68cd86
Compare
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
2 times, most recently
from
668fc27 to
d6a67cb
Compare
| @@ -90,10 +80,10 @@ func sepolia(stageName string) params.Network { | |||
|
|
|||
| return params.Network{ | |||
| ChainID: chainID, | |||
| ChainName: "Mainnet", | |||
| ChainName: "Sepolia", | |||
There was a problem hiding this comment.
Thanks for fixing this! Before it was confusing and I was not sure if it was right.
There was a problem hiding this comment.
Yeah had a chat with Ben and we decided to have a bit more separation between the mainnets and the testnets, desktop is not even using the Combined networks anymore, we're treating each chain individually.
| RelatedChainID: MainnetChainID, | ||
| RelatedChainID: common.MainnetChainID, | ||
| IsActive: true, | ||
| IsDeactivatable: false, |
There was a problem hiding this comment.
I wonder why it cannot be deactivated? Was it possible to deactivate it in the old UI?
There was a problem hiding this comment.
The element you're showing there changes the isEnabled setting, there's a new UI to toggle the isActive setting in the Profile->Wallet->Networks section.
Mainnet is disableable (as in, we let the user not include Ethereum in balances, collectibles list and activity) but it's not deactivatable (as in, we cannot let the user shut down all requests to the Ethereum chain since there's some basic functionality that depends on it).
There was a problem hiding this comment.
That's a bit confusing, should there be a indicator that tell us we cannot toggle main net
Either not show it or gray out Mainet?
There was a problem hiding this comment.
Just thinking out loud. Can we have a list of non-deactivatable networks (since they are known at compile time)
and use isEnabled for both purposes:
- let the user not include the chain in balances, collectibles list and activity
- let the user disable all requests to a chain
There was a problem hiding this comment.
@friofry the two settings serve different purposes. The list of activated networks contain those you wish to use across the whole app (for example, to send assets, collectibles, mint community tokens), the user is not supposed to change this setting very often, it's just so that networks they don't use won't make lists unnecessarily long (also since we impose a limit of 5 networks, we have to let them choose which ones they want).
The enabled setting is supposed to be local to the Wallet view, disabled networks should still show up in other parts of the app. It's supposed to be a setting the user will quickly toggle whenever they want to get an overview of their holdings in a subset of the chains they work with.
I don't think that we can merge the two settings into one (or that there's a good reason to)
There was a problem hiding this comment.
@benjthayer Yeah, some generic message on hover like "ChainX is needed for Status to remain fully operational, so it cannot be deactivated" could make things clearer for users
There was a problem hiding this comment.
@benjthayer Yeah, some generic message on hover like "ChainX is needed for Status to remain fully operational, so it cannot be deactivated" could make things clearer for users
Sounds good - what is/are the specific reason/s why the user can't turn off Mainnet? Sorry - fully anticipate this being a silly question!
There was a problem hiding this comment.
@benjthayer couple of things that depend on it:
- ENS names
- a Status new version checker service, not sure if that's functional
- address activity check
- stickers 🤡
Not sure we want to be too specific in our message though.
There was a problem hiding this comment.
@benjthayer couple of things that depend on it:
- ENS names
- a Status new version checker service, not sure if that's functional
- address activity check
- stickers 🤡
Not sure we want to be too specific in our message though.
Thanks! It was just to get a sense of the level of reliance we have on the network.
Something like this could work - better if we can keep the tooltip shorter.
| @@ -76,6 +76,8 @@ type Network struct { | |||
| ShortName string `json:"shortName" validate:"omitempty,min=1"` | |||
| TokenOverrides []TokenOverride `json:"tokenOverrides" validate:"omitempty,dive"` | |||
| RelatedChainID uint64 `json:"relatedChainId" validate:"omitempty"` | |||
| IsActive bool `json:"isActive"` | |||
There was a problem hiding this comment.
- we no longer use
manager.GetwithonlyEnabled = true GetCombinedNetworksis no longer used either
It looks like we can delete (or reuse) the isEnabled field.
There was a problem hiding this comment.
oh but we still use isEnabled client side! It's the setting indicating whether a chain is accounted for in balances, collectibles and history in the Wallet view. It should probably have a different name but I cannot change it now without breaking a lot of stuff.
rpc/network/networksevent/events.go
Outdated
| ) | ||
|
|
||
| type ActiveNetworksChangedParams struct { | ||
| ActivatedChainIDs []uint64 `json:"activatedChainIds"` |
There was a problem hiding this comment.
Maybe instead of sending these as params make a corresponding getter and send empty events?
Because if there are multiple changes, we can only process the last one.
There was a problem hiding this comment.
hmm I thought about the light/chunky signal payload problem and was slightly leaning towards the current solution, but now you've convinced me the other way, dammit.
There was a problem hiding this comment.
@friofry removed payload from the event here: 21ad7f5
This is probably the right way to do things in general for anything other than the most basic cases. We now don't need to care about order/timing of events, and we are kind of "forced" to have a more explicit dependency injection to get the data required.
| @@ -146,11 +237,15 @@ func (nm *Manager) networkWithoutEmbeddedProviders(network *params.Network) *par | |||
|
|
|||
| // Upsert adds or updates a network, synchronizing RPC providers, wrapped in a transaction. | |||
| func (nm *Manager) Upsert(network *params.Network) error { | |||
| // New networks are deactivated by default. They are also always deactivatable. | |||
There was a problem hiding this comment.
Presumably the comment applies to the new networks.
But Upsert can be used to update an existing network (it used to be the way to update RPCURL). In this case the isActive, isDeactivatable should stay as is.
Also, I wonder if we could make isDeactivatable true by default. With no option to set it to false at runtime. So the only way to make it false should be when creating it in default_networks.go
There was a problem hiding this comment.
Hmm well that's the problem with using "Upsert" to edit some network fields instead of a dedicated endpoint, there's some fields we don't want to let the user change. And that's why I deprecated the AddEthereumChain API function, which is the only place that calls this Upsert function. If mobile is not using it anymore, I'll just remove it.
There was a problem hiding this comment.
Whenever we want to bring user custom chains back we can look into it, but there's a thousand different problems with letting a user add their own chains at the moment that need to be looked into before we do that.
There was a problem hiding this comment.
That's fair. Upsert is dangerous. Or the upsert can simply apply changes manually (exclude fields that cannot be updated).
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
from
d6a67cb to
86fa895
Compare
dlipicar
force-pushed
the
feat/implement-deactiveable-networks
branch
from
21ad7f5 to
8003c9c
Compare
Part of status-im/status-desktop#17091
I swear
deactivatableis a real word: https://en.wiktionary.org/wiki/deactivatableThere's basically three parts to this PR:
IsActiveandIsDeactivatableto each network: f87f53eIsActivelets the user select which chains are available for use across the app (as opposed toIsEnabled, which simply means whether a chain is considered when displaying balances, collectibles and activity). No provider calls should occur for networks that are not active at a given time (just like what's expected of Testnet chains when the app is in Mainnet mode and viceversa)IsDeactivatablelets the client know whether a network can be deactivated. Some critical app features require specific networks to always be active (Mainnet and Sepolia).New API
SetChainActivelets the user toggle this setting. Some checks are in place to ensure only Deactivatable chains can be deactivated, and no more than 5 chains are active at a given time.Since custom chains are not supported for now
AddEthereumChainandDeleteEthereumChainare marked as deprecated. Half the app will malfunction if the client uses these endpoints to add new chains, and we've got dedicated endpoints for network user-editable fields.This is just a pub-subby way for status-go modules to react to changes in the list of networks.
Ideally we extend this to other modules which depend on the client to notify about network changes, which is more error-prone. (Separate issues status-im/status-desktop#17182 and status-im/status-desktop#17183)
The rest is just changes to make tests happy.