🧪 Announcing PicJS: TypeScript/JavaScript support for PocketIC!

[skilesare]

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.

The subnet above is my nns subnet and it looks like the cycles ledger is hosted there(https://dashboard.internetcomputer.org/subnet/uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe)

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?

[NathanosDev]

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.

[skilesare]

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.

[Severin]

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.

[zohaib29]

Does PocketIC support Bitcoin integration?

[NathanosDev]

Do you know when we could expect the cycles ledger to be included in the NNS extension?

[NathanosDev]

See @mraszyk’s comment here: Is it possible to use PocketIc to test Bitcoin integration?

[Severin]

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

[NathanosDev]

Makes sense, thanks.

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.

The subnet above is my nns subnet and it looks like the cycles ledger is hosted there(Subnet: uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe - ICP Dashboard)

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.

[skilesare]

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.

[Severin]

There’s this function that should do the trick

[skilesare]

Perfect. I’ll give it a try.

[NathanosDev]

Create an II subnet when setting up the pocket ic instance and then you can install the cycles ledger to that subnet with the correct canister id.

[skilesare]

Ah…looks like create_canister_with_id isn’t exposed from pic.js. Would it be possible to add it?

@NathanosDev Putting it in the II subnet worked. Thanks!

[NathanosDev]

There’s a targetCanisterId config option exposed on the setupCanister() and createCanister() methods that does the same thing:

• Interface: SetupCanisterOptions | PicJS
• Interface: CreateCanisterOptions | PicJS

[zohaib29]

Hi @NathanosDev, can you please answer these questions? Thanks!

[NathanosDev]

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?

I have no answer here unfortunately.

[fxgst]

@NathanosDev, @zohaib29

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

[NathanosDev]

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:
  • Jest
  • Vitest
  • Bun
• Better logging support.
  • 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.

[peterparker]

@NathanosDev

Running the PocketIC server is now detached from the PocketIC client

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.

Any ideas?

P.S.: No rush, v0.7.0 works just fine;

My PR to migrate: https://github.com/junobuild/juno/pull/508