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.
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
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?
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?