Azle Warning: setTimeout may not behave as expected

Developers
1

@lastmjs I started looking at possibly creating a wallet demo on Azle, similar to what I did with ic-alloy-basic-wallet for Rust based canisters.

Tried integrating Viem but ran into issues with AbortController is not defined. That is related to being able to cancel made HTTP/RPC requests I believe.

Also tried using ethers which kind of works. Call returns successfully but prints the following warning.

"Azle Warning: setTimeout may not behave as expected with milliseconds above 0; called with 250 milliseconds" "    at <anonymous> (azle_main:31826)\n    at perform_fn (azle_main:50468)\n    at call (native)\n    at getBlockNumber (azle_main:49687)\n    at getBlockNumber (azle_main:56013)\n    at getUnencodedResult (azle_main:31936)\n    at executeAndReplyWithCandidSerde (azle_main:31917)\n    at <anonymous> (azle_main:31962)\n"

So, if setTimeout may not behave as expected, does that mean that those calls are never executed? Or, executed with a timeout of 0?

Sorry for lumping a bunch of questions together here. :grinning: What is your sense for this? For ic-alloy I created a custom implementation using IC timers to do retries and subscriptions. Do you think that would have to be done for ethers/view as well for it to work really well? That is, creating a custom ethers/viem transport for IC.

1 Like
2

What version of Azle are you using? If you’re using the latest version, you will be forced to explicitly opt-in to experimental code. Just wanted you to know that, this is experimental territory.

The setTimeout will work, but essentially with a timeout of 0. You can’t schedule anything to be put onto the event loop in the future like a true setTimeout. I would suggest you use ICP’s timer APIs instead, if that can work for your use case.

1 Like
3

AbortController is not yet implemented in Azle experimental.

1 Like
4

Should be executed with a timeout of 0, we added the warning so that you wouldn’t think your milliseconds were actually doing anything.

1 Like
5

Yes, I do think that.

1 Like
6

Thanks for the answers! I will look and see how messy it would be to build an ICP transport for Viem. The retry/subscribe logic might or might not be located in the transport. If it is, then creating a transport would be fairly straight forward. I suspect though that the uses of setTimeout are located elswhere (only guessing) which would mean the whole library needs to be forked.

Ethers.js is an option as well of course.

1 Like