Dapp canisters control not returned

Hi,

It’s been two hours since the Juno Build SNS failed, and the control of the dapp canisters has not been handed back to me. Does it typically take a very long time for this to be completed, or is there an issue?

Canisters:

  • cokmz-oiaaa-aaaal-aby6q-cai
  • klbfr-lqaaa-aaaak-qbwsa-cai
  • fmkjf-bqaaa-aaaal-acpza-cai

Principals:

  • tpv2w-...-jqe
  • miso6-...-pqe

Proposal:

SNS aggregator:

The dApp canisters have been returned; I guess it just took some time.

Given that the feature in the NNS dApp is currently unavailable, I verified this using a yolosns script.

const {canisterStatus} = await import("https://unpkg.com/yolosns@1.2.6/dist/esm/index.js");
await canisterStatus({canisterId: "cokmz-oiaaa-aaaal-aby6q-cai"});
3 Likes

Hi @peterparker, the return of the dapp canisters happens after transferring all the ICP back to the buyers in the case of a failed swap. This happens serially and is a cross-subnet message per buyer, so it takes some time if there have been a lot of buyers. (This happens as part of finalization and finalization is known to be somewhat slow). I notice that Juno had 488 buyers, and I wouldn’t have expected it to take more than 30 seconds per buyer, so it shouldn’t have taken more than about 4 hours.

It would be really nice to add a progress bar for finalization. In the meantime, you can call dfx canister call --network ic ${SWAP_CANISTER_ID} "get_auto_finalization_status" to get a sense of what it’s doing. Running that against juno’s swap, I see that it says that it did not fail to update your dapp canisters’ controllers, which is reassuring since you said you did get control back eventually.

3 Likes

Thanks for the explanation @Andre-Popovitch, appreciated!

1 Like

Further details: It looks like finalization started at 1:00:03 pm UTC, Saturday, October 12, 2024 and finished at 2:09:04 pm UTC, Saturday, October 12, 2024. It’s very odd that you didn’t seem to regain control over the dapp canisters until after that (I think your post was made an hour after finalization was done). I wonder if there was some bad caching logic on the dashboard that made it seem to take longer than it actually did. Anyway, we will keep looking into it, thanks for reporting this!

The thing is, one of the controllers was my principal in the NNS dapp, so I didn’t notice that I hadn’t regained control of the dashboard yet, but rather in NNS dapp. Therefore, it wasn’t really a cache issue. Maybe it was just bad timing. In any case, everything is fine now. Thanks for investigating.

1 Like

Out of curiosity, why aren’t these refunds processed in parallel in batches of 200-400 (canister output queue limits are 500)? It would complete much quicker. In the case of the Juno SNS 1-2 minutes instead of 4 hours.

I think you are right: It does not need to be serial. IIRC, the NNS team has discussed parallelizing, but the priority is low.

2 Likes