What are the possible ways a canister may stop working?

Developers
1

In an attempt to better communicate with my dapp users, I’m curious what are the possible ways a canister can stop functioning.

A few reasons that came to mind:

  • The “.app” DNS registry delist the domain
  • NNS votes the canister out
  • An upgrade breaks the canister in some way (if not immutable and upgrades are allowed)
  • Canister runs out of cycles

Are you aware of any other ways that a canister might stop working?

2
  • Logic error in the code that leaves the canister in a broken state (probably the most likely)
  • You can manually stop the canister: dfx canister stop
2 Likes
3

Sometimes the most obvious reasons are those that we dismiss. Thanks for your reply

4

Can you elaborate on an example that might result in this case?

5

I was thinking of the kind of errors that you’d want to catch during testing, but somehow just miss every so often. Just simple bugs that require manual intervention, otherwise the canister either traps during execution every time, or (maybe worse) returns wrong data. It happens all the time to someone. (Certainly not me though because my code is always perfect. \s) After you get to sufficiently complex business logic, you’re almost guaranteed to have some whacky input combinations.

E.g. you have function core_business_logic(some_arguments: ???) which does the thing your canister is supposed to do. It assumes some list always contains at least 3 elements for some reason, but you overlooked a corner case (or introduced a bug) that can shrink the list down to 2 elements. Now at the beginning of your function, you simply access element 3 and (in Rust) .unwrap() the optional value. Tada, you cannot call the function properly anymore. And for this example we can just assume that this function is the only one that can append to the list. Without manual intervention, the canister is basically useless.

2 Likes