Thanks for reporting @peterparker!
Iāve published a new beta version with a fix now. I already tried it out on your branch and it works fine for me, but if you could also try it and confirm it works for you before I make a non-beta release that would be awesome.
npm i -D @hadronous/pic@beta
I can confirm, it works like a charm both locally and the CI which is green now. Thanks!
Thanks for confirming! v0.8.1 has the fix now 
Awesome! Integrated and merged. Thanks a tone, PicJS is super
Not a biggy Nathan but, I noticed this intelissense error in the global config. Not sure if itās something incorrect in my setup or an issue?
TS2345: Argument of type string is not assignable to parameter of type never
In this case itās an issue with the setup.
Your vitest.setup.ts file is located at the root of your repo, while the types.d.ts file thatās necessary for the intellisense to work is in the src/tests folder, which is excluded by the root tsconfig.json file.
In your project, I moved vitest.setup.ts into src/tests and then added "include": ["types.d.ts", "vitest.setup.ts"] to src/tests/tsconfig.json and now the intellisense works for me.
Those steps alone probably break something else, but hopefully thatās enough information for you to find a working setup.
Gotcha, thanks a lot for the quick feedback! I fixed the issue a bit differently because I like to have the configuration files at the root. So I removed the types.d.ts, exposed the module in the root vitest.setup.ts and included this latest file in the src/tests/tsconfig.json.
Thanks so much for building PicJS!
Weāre in the process of moving all of our tests over, and while right now my PicJS tests run fine locally (Macbook Pro, OSX), when I push them up to GitHub CI (Ubuntu) I get Socket error issues (which in the past has told me thereās something wonky going on with the nns state Iām using to seed Pic.
This is what the pic folder where I run my tests looks like right now
During CI, I perform the following steps:
tar -xzvf packages/pic/nns_state.tar.gz -C packages/pic/"npx jest --config packages/pic/jest.config.ts ./packages/pic/cycleops/*.test.ts"This step is where I hit the socket errors in CI but not locally, which tells me thereās something missing/different from the CI environment than my local setup (I also tried cloning a fresh repo and running CI locally which works).
Have you or anyone else run into any environment or CI issues with Pic like this?
What version of PicJS are you running? In version 0.8.1 thereās additional logging to better identity what the underlying cause of TypeError: fetch failed is.
Does this happen straight away on your first test? Or does it happen after a certain number of tests run?
If itās happening after some tests run then itās probably the Pic server being overloaded, which is the same as an issue that I was having myself on another project. I published a beta version of PicJS using the newer version of Pic server and Iām having a much better time with that.
You could try with the beta version to see if it helps your situation:
npm i -D @hadronous/pic@beta
There are some breaking changes in the PocketIc.create function and the published docs are not updated until the beta is made stable, but you can check the nns_proxy example for the relevant changes.
ā@hadronous/picā: ā^0.7.0ā,
It happens straight away, every time.
That sounds like a different issue than I had, but please try with version 0.8.1 and let me know what logs you see.
Sometimes I get this error. How to avoid this?
thrown: "Exceeded timeout of 5000 ms for a hook.
Add a timeout value to this test to increase the timeout, if this is a long-running test
That depends on why itās happening, it might be happening because the Pic server is busy and isnāt able to serve the request, if thatās the case then Iāll be releasing a new version today that will help.
If you just have long running tests, then youāll need to increase your timeout.
@NathanosDev I tried getting my state set up with an SNS approved using the SNS testing project, but something doesnāt work quite right. I think that it uses maybe a different port or something that the NNS setup example. In the same project if I give the nns_state things work great, but if I give the sns_state(the one I created using the sns-testing project) I get:
console.error
Erorr sending request to PocketIC server Error: The pending stream has been canceled (caused by: connect ECONNREFUSED 127.0.0.1:57046)
at closeSession (node:internal/http2/core:1153:20)
at ClientHttp2Session.destroy (node:internal/http2/core:1543:5)
at Socket.socketOnError (node:internal/http2/core:3006:13)
at Socket.emit (node:events:518:28)
at Socket.emit (node:domain:488:12)
at emitErrorNT (node:internal/streams/destroy:169:8)
at emitErrorCloseNT (node:internal/streams/destroy:128:3)
at processTicksAndRejections (node:internal/process/task_queues:82:21) {
code: 'ERR_HTTP2_STREAM_CANCEL',
cause: Error: connect ECONNREFUSED 127.0.0.1:57046
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16) {
errno: -61,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 57046
}
}
Is there perhaps some port I can tweak to get things working?
I basically followed this process: GitHub - dfinity/sns-testing: Testing SNS in local testing environment.
And then harvested the state from my library/Application Support directory instead of a local directory.
I was also careful to pull the proper subnet id out as described in your guide.
I was able to get it to spit out:
Jun 26 23:59:33.284 CRIT s:/n:/ic_state_manager/ic_state_manager Failed to load checkpoint @5400: /var/folders/7l/thqhv3nn75b3t1hz1wj3bzrr0000gn/T/.tmpxx6czB/checkpoints/0000000000001518: failed to deserialize SystemMetadata: Replica does not implement certification version 16
thread 'tokio-runtime-worker' panicked at rs/state_manager/src/lib.rs:1473:21:
Failed to load checkpoint @5400: /var/folders/7l/thqhv3nn75b3t1hz1wj3bzrr0000gn/T/.tmpxx6czB/checkpoints/0000000000001518: failed to deserialize SystemMetadata: Replica does not implement certification version 16
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at rs/pocket_ic_server/src/state_api/routes.rs:576:10:
Failed to launch PocketIC: JoinError::Panic(Id(20), ...)
I think this sns tool uses dfx 0.19.0 and I wonder if that is the issue. Iāll try to force it to use 20.1
Edit:
Running the process with 0.20.1 gives a similar error by the certification version is updated:
Jun 27 00:34:29.195 CRIT s:/n:/ic_state_manager/ic_state_manager Failed to load checkpoint @2200: /var/folders/7l/thqhv3nn75b3t1hz1wj3bzrr0000gn/T/.tmpxNxdln/checkpoints/0000000000000898: failed to deserialize SystemMetadata: Replica does not implement certification version 18
thread 'tokio-runtime-worker' panicked at rs/state_manager/src/lib.rs:1473:21:
Failed to load checkpoint @2200: /var/folders/7l/thqhv3nn75b3t1hz1wj3bzrr0000gn/T/.tmpxNxdln/checkpoints/0000000000000898: failed to deserialize SystemMetadata: Replica does not implement certification version 18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at rs/pocket_ic_server/src/state_api/routes.rs:576:10:
Failed to launch PocketIC: JoinError::Panic(Id(20), ...)
Roping in @michael-weigelt and @mraszyk as I see theyāve answered a ton of Pocket IC questions.
Replica does not implement certification version 18
This error suggests that youāre using a state produced by a different version of the replica.
I tried getting my state set up with an SNS approved using the SNS testing project
Since the replica version of dfx in the SNS testing project might be incompatible with the replica version used in PocketIC.
Is there some place to see which dfx is compatible with each pocket ic version?
In the latest dfx version, PocketIC is part of it and thus they match. Beyond that, we donāt track compatibility.
@NathanosDev Is picjs updated to this latest version?
Apologies for the late response, I was travelling last week.
@mraszyk is there a way to check what version of the replica is being used by PocketIC?
@Severin is there a way to check what version of the replica is being used by DFX?
At least then I can maintain a compatibility table to avoid other devs being tripped up by this.
@NathanosDev Is picjs updated to this latest version?
The current beta version of PicJS is using the latest version of PocketIC. I expect to make a stable release this week and I donāt expect to be any changes so thereās no concerns with using the beta version now.