Currently we made provider deregistration 2-step (#80), but that may still be suboptimal. We need to think about ease of use locally as well, as e.g. #96 showed that the state remains polluted between test runs due to deregistration period not having passed. In that case it was circumvented with a sudo fast-forward, but there might be something more optimal overall.
Details
Fair point for the runtime, and good to know it's covered. Here though the problem was for local reruns on the same global setup: the account used for acknowledging the UI state didn't completely deregister, so it never saw the right screen. But I guess instead of skipping that particular test if the Ferdie account is already there like I did initially I'll try sudo removing the thing to make tests more reproducible. Not that it's a CI problem, but still.
@ilchu For decentralization, I would not use sudo on specific logic.
Originally, the provider deregistration flow is just check if provider's commit_bytes is 0; to be more specific we should check provider is not in charge any buckets. This way provider can instantly leave; but to do that, we have to iterate the whole buckets storage to examine (not cost effective).
My fixes introduce provider deregistration in 2 steps may not ideal as well. However, we can fallback to original with additional storage mapping to trace provider's buckets easier, or when look deeper there are better solutions for this.
Let's open a issue for this, we'll investigate more.
Originally posted by @danielbui12 in #96 (comment)
Currently we made provider deregistration 2-step (#80), but that may still be suboptimal. We need to think about ease of use locally as well, as e.g. #96 showed that the state remains polluted between test runs due to deregistration period not having passed. In that case it was circumvented with a sudo fast-forward, but there might be something more optimal overall.
Details
@ilchu For decentralization, I would not use sudo on specific logic.
Originally, the provider deregistration flow is just check if provider's commit_bytes is 0; to be more specific we should check provider is not in charge any buckets. This way provider can instantly leave; but to do that, we have to iterate the whole buckets storage to examine (not cost effective).
My fixes introduce provider deregistration in 2 steps may not ideal as well. However, we can fallback to original with additional storage mapping to trace provider's buckets easier, or when look deeper there are better solutions for this.
Let's open a issue for this, we'll investigate more.
Originally posted by @danielbui12 in #96 (comment)