Any suggestions on how to add the cycles ledger? Is it supposed to go on the NNS subnet? Or some other subnet?
Unsuccessful validation of specified ID: Specified CanisterId um5iw-rqaaa-aaaaq-qaaba-cai is not hosted by subnet erfz5-i2fgp-76zf7-idtca-yam6s-reegs-x5a3a-nku2r-uqnwl-5g7cy-tqe.
Maybe because Iām using the dfx state it has a different range? Any way I can change the range to include that? Maybe with DFX 19 I can get a better state that already has the cycle ledger in it?
Can pic give me the equivalent of the dfx output that has these logs in it?
I originally had support for logging everything to a file, but it was causing issues specifically on Mac so I removed it for now. I havenāt had time to investigate into why that was happening, but I can probably spend time on it this weekend.
My process isnāt stoping properly so Iāve likely messed something up, but I can see my debug statements now!
What JS runtime and test runner are you using? NodeJS and Jest?
Maybe with DFX 19 I can get a better state that already has the cycle ledger in it?
Maybe @Severin will know the status of the cycles ledger and itās integration with the NNS extension for DFX.
Maybe because Iām using the dfx state it has a different range?
Yes, exactly.
Any way I can change the range to include that?
Not that Iām aware of, I think youāll need to use a principal from the range for the subnet. Iām not sure how to check what the range is either, but I can probably find out if there is no support for the cycles ledger in the DFX NNS extension.
Iām using jestā¦Probably the ttl on the serverā¦A cancel op via the keyboard kills it with no problem. Possibly when I hit an error, tearDown isnāt being called.
If you use nns extension v0.3.1 (dfx extension install nns --version 0.3.1, but it should pick the right one by default) the CMC is set up to connect to the cycles ledger properly to mint cycles directly to the cycles ledger. If you donāt need that function (notify_mint_cycles) then donāt worry about the extension version.
For now the cycles ledger is not included in the nns extension so you have to install it separately.
So far we didnāt plan to add the cycles ledger to the nns extension since 1) we donāt think of the cycles ledger as part of the NNS (for now) and 2) we didnāt really expect there to be much demand. Do you think it should be part of the dfx exension (where on local youāre likely to skip the cycles ledger anyways)? My instinct is more that it should be very straightforward to add it to PocketIC setups (and we could provide a function, code snippet, or crate for that) instead of adding it to the nns extension
I donāt know if it makes sense to be part of the DFX extension since I donāt know what the use case is yet, but maybe @skilesare could fill us in on that.
Checking this again, this is the II subnet, so it should be possible to setup an II subnet in your tests, then install the cycles ledger to the correct canister Id.
I think the main difficulty here is in fetching the WASM and making it available to your test setup. This is something Iād love to streamline in PicJS somehow, possibly by integrating with DFX pull.
The main issue is that Iād really like the cycles ledger to have the same canister id as it does in mainnet like the NNS does when I capture state. Iām not sure how to accomplish this. Maybe I can set it up in the local replica and get it in the initial state if I can figure out how to assign an id on the local replica.
Answered the questions that I know the answer to, the other questions I think @mraszyk will know better:
Is there any difference in cycle consumption for different subnets types or not? (Can we use PicJS to test cycle consumption for our canister methods?)
Iām pretty sure the answer to this is yes, but could you confirm @mraszyk?
What is the purpose of Bitcoin subnet, if the Bitcoin Integration is not supported?
Is there any difference in cycle consumption for different subnets types or not? (Can we use PicJS to test cycle consumption for our canister methods?)
With the latest PocketIC, we model cycles consumption like on mainnet. This means that canisters on e.g., System, Application and Fiduciary subnets will consume as many cycles as on their mainnet counterparts.
What is the purpose of Bitcoin subnet, if the Bitcoin Integration is not supported?
The Bitcoin subnet reserves the canister IDs like on mainnet. If you want to install the Bitcoin canisters (manually!), you should do it on the Bitcoin subnet type, if you want to have the same canister ranges (and IDs) like on mainnet.
Iāve just published v0.8.0 of PicJS with three main changes for consumers:
Running the PocketIC server is now detached from the PocketIC client, and Iāve added some new guides showing how to handle this with some of the more popular testing frameworks. Feel free to let me know if youāre using a framework not covered here:
Some unrecoverable scenarios, such as the PocketIC server being overloaded, were previously hidden behind a Error: Failed to fetch message. Now more explicit messages are logged to the console.
Consumers can also configure separately the canister logs, PocketIC server logs and the IC runtime logs. This is covered in the Running tests guide.
Added a new processingTimeoutMs option to the PocketIc.create() method that allows for configuring how long youāre willing to wait for a response for the PocketIC server. This is convenient for cases where the PocketIC server is overloaded and youād rather fail the test fast instead of waiting for the call to timeout.
Thanks for the heads-up, Nathan. After migrating to v0.8.0 and following the documentation to set up a global script, Iāve encountered a few tests that end up timing out.
One suite ends in timeout when running all tests but not in standalone. The other fails in any case.