Question: How do I make an inter_canister call from the post upgrade hook?

[saikatdas0790]

I am trying to make an inter-canister call to call another canister on a successful upgrade. However, it looks like post_upgrade cannot be async. This is the error that I’m seeing:

#[post_upgrade] must be above a function.
expected one of: for, parentheses, fn, unsafe, extern, identifier, ::, <, square brackets, *, &, !, impl, _, lifetime

How do I achieve my desired outcome? Thoughts?
@roman-kashitsyn @chenyan

[skilesare]

Maybe use the new timer api to call your function after 1 nano second…it should be the next thing called most of the time. You can add a halt blocker if you need a guarantee.

[saikatdas0790]

This might work. Let me try.

Although, seems to be a total hack.

What’s a “halt blocker”?

@skilesare

[skilesare]

Just do a check of a bool at the top of every update function. Set it to false at the end of your post upgrade and true at the end of your timer.

[saikatdas0790]

It does not work. Basically, a timer expects a function that doesn’t return anything whereas an async fuction returns a type of Future. The function has to be an async function because inter canister calls are async and need to be await-ed.

This is the error message I see:

error: expected fn() -> impl Future<Output = ()> {add_one} to be a fn item that returns (), but it returns impl Future<Output = ()>
label: required by a bound introduced by this call

Any other ideas? Curiously, does this workaround work in Motoko?

@skilesare

[mparikh]

Use spawn.

Heartbeat improvements / Timers [Community Consideration]

Is there a way to call async functions (i.e. raw_rand()) within the function invoked by set_timer/set_timer_interval?

[saikatdas0790]

Thank you. This worked. Although there’s a minor caveat.

Calling spawn directly from the post_upgrade doesn’t work. It generates the following error.

“ic0_call_new” cannot be executed in init mode

However, calling the timer with a nanosecond delay and using spawn with the async function inside it works. Like this:

ic_cdk::timer::set_timer(Duration::from_nanos(1), || ic_cdk::spawn(add_one()));

[paulyoung]

This has come up in other threads too:

Cross-canister compatible Post-Init hook

TLDR; Would a post-init hook that allows cross-canister calls be beneficial? I have a need to make a cross-canister call one time, at canister initialization (see this post). However, neither the init method nor the post-upgrade method allow for cross-canister calls. As a result I have to find another way to kick this off. Current possible solutions include: Using heartbeat Exposing a separate dedicated canister method Using the new timer API The heartbeat method would be too expensive. H…

I think @icme was proposing that there could be new lifecycle hooks for this purpose:

Canister Lifecycle Hooks

A lifecycle hook or method is a common way of allowing developers a passive way to tie into and handle the occurrence of specific and important events. In the context of React and Angular, lifecycle hooks allow developers to tie into a component mounting or state changes, and in the context of AWS EC2 these hooks are triggered when auto-scaling an instance. On the IC, developers are currently able to actively interact with canisters but are limited in their ability to passively tie into specifi…

[paulyoung]

I think the caveat with this approach based on the threads I linked to is that it doesn’t guarantee that other messages aren’t processed before your timer function is called.

That might be fine for this use case depending on what you want to do.

[saikatdas0790]

Yep, this is a HACK. But it gets me unstuck for now.

Would definitely appreciate a well thought out alternative, though.

[mparikh]

Put it another way, perhaps if all messages were to be dropped for all update calls to the canister, that might work?

I will make a change to dos(GitHub - icdev2dev/dos: Some Denial of Service Defenses for SmartCanisters on IC) to add a proposal type of ‘*’ to accommodate this.

The query calls would still need guards.