__motoko_runtime_information not properly displayed in dfx

[luc-blaeser]

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;
  },
)

[crusso]

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 #4635

[ggreif]

@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!

[crusso]

Doc: https://internetcomputer.org/docs/current/developer-docs/developer-tools/cli-tools/cli-reference/dfx-canister#options

[ByronBecker]

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?

[ByronBecker]

@ggreif

[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;
}

[ByronBecker]

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

[ggreif]

I filed an issue in SDK's internal Jira. The suspicion is that when the metadata retrieval was implemented the --candid option became dysfunctional.