Rust CDK release v0.6.8

Developers Rust
1

I’m happy to announce that Rust CDK 0.6.8 is out.

This version includes support for a couple of new IC features:

Canister Timers

Now, you can set timers for canisters. This feature allows a more flexible way to schedule later works. Compared with the existing heartbeat mechanism, Canister Timers allows:

  • set both one-time and repeating jobs;
  • set multiple jobs with different time intervals;
  • cancel timers set before

Check the example for how to use it.

Composite query

Tagging a function with #[query(composite = true)] will make it a composite query.

Composite queries can call other query functions (both queries and composite queries), but cannot be called in replicated mode.

For more details about composite queries, please check these forum threads:

Huge thanks to @AdamS who implemented both features!

Enjoy building canisters on IC with the improved Rust CDK!

18 Likes
2

Please note that composite queries are available only for local development and testing. They are not released on the mainnet yet.

8 Likes
3

Great work!
In general what is Dfinity’s plan for Motoko/Rust features. Do you guys try to do them at the same time?

3 Likes
4

We attempt to support a new feature in Rust/Motoko before the feature is enabled on the IC mainnet. So that canister developers can develop/test with new functionalities early and deploy as soon as they are available on the mainnet.

Rust/Motoko CDK are developed separately. When a CDK implements support for a new feature, it will be released right away. There is no release syncing between these two CDK.

4 Likes
5

Any thoughts on which ic-state-machine-tests commit we should be referencing to be able to test these features in our integration tests?

1 Like
6

Intuitively I would go for the commit that is either deployed on your subnet or in your current dfx version

2 Likes
7

@Severin
So, I’m trying to figure out how to make this work.

If this is my subnet, how would I figure out the release commit hash?

I wasn’t quite sure how to figure the commit for the dfx version as well. I’m on DFX 0.12.1, btw

I also tried to make it with the latest blessed replica release which is this:

But I’m getting the following errors when building my Cargo project

image
image1073×962 127 KB

Any thoughts?

P.S. This is the commit that builds without breaking for me right now

8

You go to this page on the dashboard and Ctrl+F for your subnet’s ID. Using that, I see that the latest version update proposal for your subnet is this one. From there you can see that it’s running replica version 0cbb2e9c7683f4cd91f77e8ab0d65f6cb90c0387 right now.

Go to the dfx release notes and scroll down to the section ‘Dependencies’ for your current release. For 0.12.1 it shows a replica commit of dcbf401f27d9b48354e68389c6d8293c4233b055.

As for the Cargo error: I haven’t tried to work with state machine tests ever, so I don’t think I can help with that. @roman-kashitsyn would be the right person to ask

1 Like
9

I managed to make it work.

For future readers, the trick is to ensure the protocol buffers compiler protoc and additional include files are installed.

I installed it from here

1 Like
10

It would be nice to somehow indicate to developers when a feature is truly live. I usually have to understand a combination of cdk-rs version, dfx version, and IC replica version deployed to subnets before understanding when a feature is truly live.

For example, cdk-rs now has timers, but which dfx version has it (hypothetical question, I’ve been told dfx 0.12.1), and does that mean it’s live on the IC?

4 Likes
11

Good idea. We should add version requirements to these release notes for such features. I’ll let the team know

3 Likes
12

Good point, @lastmjs

14

Just a quick question to confirm this is now live on the IC correct?

Thanks.

15

Yes, that’s correct.

1 Like
16

Thanks for that quick reply, good news @Severin!

1 Like
17

I’ve been hitting a brick wall for the last few days with some Rust code which seemed to stop, discard data and then re-run… all without throwing an error! Turns out a function which was being called by a timer was hitting the computation/ instruction limit.

This was apparent when calling the function via a manual update method (which would trap and return the error). I’m interested if it’s possible to handle/ log such situations with a timer function?