Over the past few months, PocketIC has become a great tool for canister testing because of PocketIC itself but also due to its many client libraries. It is now at a point where it covers the functionalities the replica offers in dfx, plus some more. All dfx tests in CI are now running on both dfx start --replica and dfx start --pocketic without substantial differences.
At this point we (the SDK team) believe that running the replica instead of PocketIC with dfx no longer offers enough benefits to warrant including the replica in dfx releases. Therefore we plan to remove replica support from dfx in three stages:
Stage 0: (you are here)
dfx start --replica runs the replica
dfx start --pocketic runs PocketIC
dfx start runs the replica
Stage 1: (first beta release a few weeks from now)
dfx start --replica runs the replica (unchanged)
dfx start --pocketic runs PocketIC (unchanged)
dfx start runs PocketIC (new!)
Stage 2: (first beta release ~1-2 months after Stage 1 was fully released)
dfx start --replica no longer exists (new!)
dfx start --pocketic runs PocketIC (unchanged, will be removed at some point in the future)
dfx start runs PocketIC (unchanged)
As a result of this, dfx will become ~25% smaller to download, the local deployments will run faster, and we can support a lot of new, very useful features such as the recently implemented option to impersonate arbitrary principals when calling canisters.
We’re happy to answer questions or address any concerns that you may have.
Thanks for the update. Nice to see you guys still adding more features to PocketIC. This tool is hands down one of the best features allowing us to ship more robust and tested code and ultimately continue developing more instead of fixing bugs so big well done to you and the team. Is there a roadmap of features for Pocket IC?
A few details on how config will change would be helpful for planning. Specifically:
Pocket-ic allows for multi-subnet…this will be a huge help for testing. How will we set that up?
Pocket-ic via the programming interface gives some nice controls over manipulating the clock and specifying how many ticks go by. Will we have that kind of control via dfx?
Were @Gekctek 's issues with the HTTP server and the requests ever resolved? I know that the replica currently handled the boundary node functionality and I’m curious if/how this might change.
Will there be any issues with extensions like the nns install?
Out of curiosity, how will this new PocketIC setup work with full-stack dev? I’ve only used PocketIC with tests (picJS)
For example, if my repo has a script that:
Starts up dfx with --pocketic
Triggers a bunch of dfx & agent-js commands to deploy canisters and then configure them correctly.
Will this just work without any changes? And not just in scripting but in receiving any calls from the agent (i.e. if doing local frontend dev against the local dfx pocketIC setup)?
Will we need to perform the ticks manually ourselves or with all the asynchronous calls execute synchronously unless explicitly deferred?
@mraszyk can answer this better than I. A bare minimum is supporting mainnet features. Beyond that I couldn’t find a recent document.
In dfx start we have some reasonable default (currently this) and maybe a little bit of customization via CLI parameters. But if you want detailed control over the exact setup you probably want to use a PocketIC client library and use proper code to get exactly what you want.
I don’t see a strong reason against, and we could use it in dfx tests occasionally as well. It’s mostly a prioritization thing. I created this feature request so we can get some numbers on how many people care about it. Please upvote if you care about it
I think(?) the issues were resolved. The replica never handled boundary node functionality, at least not since I joined ~3 years ago. First, icx-proxy did the boundary node tasks. Since dfx 0.23.0 we swapped that out for the gateway contained in PocketIC to handle boundary node tasks for both replica and PocketIC
We don’t expect any, and even hope that it would make the extension more useful by e.g. being able to restore state from a snapshot file so dfx nns install could be completed within a few seconds instead of the 1-2ish minutes it takes on my machine.
Yes, assuming we don’t have bugs this will work as before.
dfx starts PocketIC with auto_progress enabled, so there is no need (and at the moment no ability) to tick manually.
