New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the heartbeat #2728
Comments
Shouldn't be too hard to support. |
Yeah, the straight forward exposition should be almost trivial. Is our type system strong enough to express a context that allows calls (i.e. can await), but does not allow responses? That might new, or affect the default reject handler. |
Not entirely sure, but it sounds like the same restrictions we enforce on oneways by forcing the ignore async {...} abomination. |
Hi Claudio, any chance we can get this added? Right now I have to install a separate rust heartbeat canister to call my motoko ones, this isn't very ideal 😅 |
This definitely sounds useful for any Motoko app that needs cron-like functionality. You might've seen this, but here is an example of a Rust canister that uses the heartbeat: https://github.com/akhi3030/heartbeat-example/blob/master/src/lib.rs |
Here is my very naive & hacky attempt at implementing it ninegua@6a0a645 Probably made a lot of mistakes, and I don't have time to write any test case. It is better to wait for official implementation. Example:
|
(I would probably make it just return |
Fine by me! |
That was my first try. But with only Also my suggestion is to rename |
Any update on this? Thanks! |
Please give my canister a heartbeat. |
@roman-kashitsyn leaked on the forum that the
canister_heartbeat
entry point is now supported by application subnets. The Interface spec doesn’t list it yet, but once it’s there we should probably support it from Motoko.Unless we take the stance (from the discussion on the feature in the
ic-ref
at https://github.com/dfinity-lab/ic-ref/issues/245, which I can’t read any more) thatcanister_heartbeat
is a low-level feature meant to be used mainly by canisters providing cron services to other canisters, and that Motoko canisters should not use this (inefficient, inflexible) interface, but should rather use dedicated cron-as-a-service-canisters.But the pragmatic thing is probably to expose the
canister_heartbeat
entry point.The text was updated successfully, but these errors were encountered: