Skip to content
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

Closed
nomeata opened this issue Aug 17, 2021 · 12 comments · Fixed by #3039
Closed

Support the heartbeat #2728

nomeata opened this issue Aug 17, 2021 · 12 comments · Fixed by #3039

Comments

@nomeata
Copy link
Collaborator

nomeata commented Aug 17, 2021

@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) that canister_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.

@crusso
Copy link
Contributor

crusso commented Aug 17, 2021

Shouldn't be too hard to support.

@nomeata
Copy link
Collaborator Author

nomeata commented Aug 17, 2021

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.

@crusso
Copy link
Contributor

crusso commented Aug 30, 2021

Not entirely sure, but it sounds like the same restrictions we enforce on oneways by forcing the ignore async {...} abomination.

@FloorLamp
Copy link
Contributor

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 😅

@jzxchiang1
Copy link
Contributor

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

@ninegua
Copy link
Member

ninegua commented Nov 12, 2021

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:

import Debug "mo:base/Debug";

actor {
    var count = 0;
    public shared func inc() : async () {
        count := count + 1;
        Debug.print("count = " # debug_show(count));
    };

    system func heartbeat() : async () {
        Debug.print("heartbeat");
        ignore inc();
    };
};

@crusso
Copy link
Contributor

crusso commented Nov 15, 2021

@ninegua thanks for that! Looks quite plausible (skimming only)

@rossberg shall we add support for the heartbeat method?

@crusso
Copy link
Contributor

crusso commented Nov 15, 2021

(I would probably make it just return (), not async(), like a oneway though.)

@rossberg
Copy link
Contributor

Fine by me!

@ninegua
Copy link
Member

ninegua commented Nov 17, 2021

(I would probably make it just return (), not async(), like a oneway though.)

That was my first try. But with only () I cannot make it pass the type checker if I have ingore inc() in the function body. Maybe you can help?

Also my suggestion is to rename upgrade { .. } record to system { ... } to better match the intention.

@jzxchiang1
Copy link
Contributor

Any update on this? Thanks!

@ggreif ggreif linked a pull request Jan 7, 2022 that will close this issue
@Motokoder
Copy link

Please give my canister a heartbeat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants