Help! In http_req and cron-jobs vs heartbeat

Developers
1

I want to implement cron jobs in a canister for some state update calls.
I considered two methods :slight_smile:

  1. Using Heartbeat function, but I have experienced and saw in many community talks that heartbeat function is quite expensive! So I just want to know how expensive it can be (I have an idea how ex. they are but just want to get clear).
  2. I thought of using third party cron-jobs who can hit http_req. But I am not sure if http_req can update state of canister. So If someone can help me with good example of how to use http_req to update state of can, because i tried it, but having errors.

I know there are previous posts over http_req, but none of them hepled me with update call thing, and please give me an example of how to hit that http_req from browser to update state, tht would be very helpful. Thanks in advance.

1 Like
2

I’d start with this example by @nomeata, and see if that helps you. You should be able to update state from a properly defined call, you just have to think about the implications of other actors hitting that endpoint (e.g. ensure that the logic is always canister-side, and doesn’t take parameters from the unauthenticated call).

1 Like
3

A third option would be to use some cloud function provider. They typically provide a cron-like functionality and would allow using an agent library directly to talk to the IC.

1 Like
4

thanks for this, but can you please tell :

#[update]
fn http_request_update(req: HttpRequest) → HttpResponse {
dispatch(req)
}

Where and how this can be used to update state of same canister, or to call update methods inside this http_request_update ?

5

(emphasis mine)

My telegram canister, GitHub - nomeata/ic-telegram-bot: A telegram bot on the Internet Computer , handles this request, and decodes the JSON using an existing Telegram Rust library (big :heavy_plus_sign: for using existing programming languages on-chain here) to peek inside. It looks in the message text for /telljoke, extracts the jokes, remembers it, and replies a response with upgrade.

NB: This was a query method, so even though the code looks like the bot has now stored the new joke, it actually hasn’t.

The reply is an IC-style reply, and is received by the icx-proxy. It notices that upgrade = true, and instead of simply producing a HTTP response like usual, this flag causes it to issue another call to the canister, but this time an update call to the http_request_update method . This is the new feature added by @paulyoung.

My telegram bot actually uses exactly the same code as before to handle the request. This is a bit redundant – I could have replied to the first query with a mostly empty response and just the flag set to true – but I was lazy and it doesn’t make much of a difference. It also doesn’t matter that upgrade = true is now set again in the response; it’s simply ignored. What matters is that this is now an update method, so the state change is preserved by the Internet Computer.

This time the reply, which carries a Candid-encoded HTTP response, is turned into a proper HTTP response by icx-proxy and returned to the Telegram server, causing a Telegram message to be sent to you. Here I am using a very nifty feature of the Telegram bot API: It allows me to send my bot’s response directly in the HTTP response to the Telegram’s server request. This is crucial to make this work, as discussed below.

What happened here, briefly: The IC canister now has a way of telling the nginx proxy to re-issue a request as an update (by setting a flag in the response). @nomeata took advantage of this feature, and took a shortcut in leaving the “save to memory” code there two times, even if the first time it doesn’t actually commit to memory. It will get stored on the next call, that will be an update call.

2 Likes