# Issues with ic\_cdk::spawn and Inter-Canister Calls

**URL:** <https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481>\
**Category:** Rust\
**Created:** [September 24, 2024, 10:44am UTC](https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481 "2024-09-24T10:44:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![gravity\_vi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gravity_vi/32/35810_2.png) [@gravity\_vi](https://forum.dfinity.org/u/gravity_vi)\
**Post date:** [September 24, 2024, 10:44am UTC](https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481/1 "2024-09-24T10:44:48Z")

</div>

We are using `ic_cdk::spawn` to make inter-canister calls and have encountered some unusual behavior—specifically, it seems that some of the calls to canisters are not being executed. Could you help us understand what might be causing this?

Do `ic_cdk::spawn` calls get dropped during canister upgrades? For context, we utilize `ic_cdk::spawn` within periodic timers and ensure that we re-enqueue them in the `post_upgrade` function.

To clarify, our periodic timer function performs two main tasks:

1. Calculates the outcome of the bets placed.
2. Informs the participants of the bet, which involves inter-canister calls using `ic_cdk::spawn`.

While we observe that step 1 is consistently executed, we are experiencing failures with step 2 in some instances. Any insights you could provide would be greatly appreciated.

---

<div class="post-metadata">

**Author:** ![AdamS](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/adams/32/5248_2.png) [@AdamS](https://forum.dfinity.org/u/AdamS)\
**Post date:** [September 24, 2024, 5:20pm UTC](https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481/2 "2024-09-24T17:20:58Z")

</div>

Just about anything you don’t personally serialize to stable memory is transient wrt canister upgrades and will be cleared. This includes timers (as you seem to be already aware of), spawned futures, and the necessary bookkeeping to receive in-flight canister calls’ return values. I recommend stopping canisters before upgrading them (`dfx canister stop`) if you are losing canister call related continuity because of upgrades.

---

<div class="post-metadata">

**Author:** ![gravity\_vi](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gravity_vi/32/35810_2.png) [@gravity\_vi](https://forum.dfinity.org/u/gravity_vi)\
**Post date:** [September 25, 2024, 5:45am UTC](https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481/3 "2024-09-25T05:45:54Z")

</div>

Thank you for clarifying. We do stop canisters before upgrading them. If we stop the canister, will the existing spawned futures still be executed, or could they potentially be dropped?

---

<div class="post-metadata">

**Author:** ![AdamS](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/adams/32/5248_2.png) [@AdamS](https://forum.dfinity.org/u/AdamS)\
**Post date:** [September 25, 2024, 10:56pm UTC](https://forum.dfinity.org/t/issues-with-ic-cdk-spawn-and-inter-canister-calls/35481/4 "2024-09-25T22:56:43Z")

</div>

Stopping the canister will wait for any incoming calls to complete, but other things like timers may not be executed in the meantime. Since you are scheduling calls from timers, if you observe a stop-upgrade-start workflow dropping calls, it is more likely that the timers aren’t successfully being re-enqueued. A reproducible example would help a lot.