`__motoko_runtime_information` not properly displayed in `dfx`
When calling:
dfx canister call backend __motoko_runtime_information "()"
users now don't see field names with recent Motoko/dfx versions:
(
record {
57_464_665 = false;
555_875_341 = 32_760 : nat;
840_817_809 = 0 : nat;
846_809_255 = "0.1";
1_189_611_882 = 256 : nat;
1_859_442_917 = 2_097_152 : nat;
1_942_499_641 = "0.13.4-4-g6603c0ac2";
2_211_011_332 = 32_760 : nat;
2_443_866_118 = 0 : nat;
3_253_100_504 = "default";
3_814_221_704 = 0 : nat;
3_844_882_150 = 0 : nat;
4_056_661_757 = 0 : nat;
4_069_829_730 = 2_228_224 : nat;
},
)
I suspect this never worked when called from dfx unless it had some special support that was removed.
The internal tests just cast the motoko actor to an actor type exposing the function at the correct type.
If we want this to work in general, I think we would need to add this method and perhaps other well-known methods to the candid interface.
Related PR https://github.com/dfinity/motoko/pull/4635
@ByronBecker Try the dfx option:
--candid <CANDID>
Provide the .did file with which to decode the response. Overrides value from
dfx.json for project canisters
It might just work!
Doc: https://internetcomputer.org/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#options
Trying this out with
dfx canister --ic call <my_canister> __motoko_runtime_information --candid internal_stats.did
Where the internal_stats.did file is 👇
type RuntimeInformation = record {
compilerVersion : Text;
rtsVersion : Text;
garbageCollector : Text;
memorySize : Nat;
heapSize : Nat;
totalAllocation : Nat;
reclaimed : Nat;
maxLiveSize : Nat;
stableMemorySize : Nat;
logicalStableMemorySize : Nat;
maxStackSize : Nat;
callbackTableCount : Nat;
callbackTableSize : Nat;
};
service : {
__motoko_runtime_information : () -> (RuntimeInformation) query;
}
And I'm receiving this back:
(
record {
57_464_665 = false;
555_875_341 = 157_746_608 : nat;
840_817_809 = 139_597_484 : nat;
846_809_255 = "0.1";
1_189_611_882 = 256 : nat;
1_859_442_917 = 2_097_152 : nat;
1_942_499_641 = "0.12.1";
2_211_011_332 = 241_247_228 : nat;
2_443_866_118 = 0 : nat;
3_253_100_504 = "copying";
3_814_221_704 = 83_500_620 : nat;
3_844_882_150 = 0 : nat;
4_056_661_757 = 848 : nat;
4_069_829_730 = 366_673_920 : nat;
},
)
Anything you can see from first glance that might be off?
@ggreif
That's sad. Did you try with
service : {
__motoko_runtime_information : () -> (record {
compilerVersion : Text;
rtsVersion : Text;
garbageCollector : Text;
memorySize : Nat;
heapSize : Nat;
totalAllocation : Nat;
reclaimed : Nat;
maxLiveSize : Nat;
stableMemorySize : Nat;
logicalStableMemorySize : Nat;
maxStackSize : Nat;
callbackTableCount : Nat;
callbackTableSize : Nat;
}) query;
}
@ggreif Nope, didn't make a difference. Same output. Tried with both dfx 0.24.0 and 0.24.3.
Maybe you can try deploying a canister to mainnet and seeing if the response is clean on your side?
I think we would need to add this method and perhaps other well-known methods to the candid interface
Yes, or glue together the candid with dfx?
@crusso This gets to another point that I'd like to bring up, which is allowing Motoko canisters to explictly specify private APIs that aren't meant to be discoverable or viewable from the dashboard. Specifically for product/team administrators.
I filed an issue in SDK's internal Jira. The suspicion is that when the metadata retrieval was implemented the --candid option became dysfunctional.
Here: https://dfinity.atlassian.net/browse/SDKTG-420
@ggreif @crusso just checking in - has this issue been resolved in a newer version of dfx?