-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR tokio-runtime-worker jsonrpsee_server::transport::ws: WS transport error: i/o error: Transport endpoint is not connected (os error 107); terminate connection: 0 #1108
Comments
so i installed netstat with
so i modified the docker-compose.yml file with then when i entered the container's shell it showed a lot more active connections when i ran |
Someone else encountered this same error https://substrate.stackexchange.com/questions/7361/ink-contract-upload-error. The Dockerfile was configured to get the latest commit of https://github.com/paritytech/substrate-contracts-node, so i was using the following in the docker container: Substrate Contracts Node version 0.25.0-a2b09462c7c
and the Cargo Contracts version used is
But what confuses me, is that the latest commit of this repo that i'm using 7253c6a, shows that it's using these dependencies:
whilst the latest commit of https://github.com/paritytech/substrate-contracts-node/blob/main/runtime/Cargo.toml#LL31C119-L31C135 uses
but the latest commit in branch "polkadot-v0.9.42" in the "pallet-contracts" package of the Substrate repo here https://github.com/paritytech/substrate/blob/polkadot-v0.9.42/frame/contracts/Cargo.toml#L45 uses
So the latest commit of "cargo-contract But if we use the paritytech/scripts they generate an image using the latest commit in the 'master' branch of the "cargo-contracts" repo here https://github.com/paritytech/scripts/blame/master/dockerfiles/contracts-ci-linux/Dockerfile#L61 and the latest commit of the 'main' branch of the "substrate-contracts-node" repo here https://github.com/paritytech/scripts/blame/master/dockerfiles/contracts-ci-linux/Dockerfile#L65 |
So my next step is to follow https://use.ink/getting-started/setup and install a specific older version substrate-contracts-node instead of its latest commit with:
and install the latest stable version of cargo-contract instead of the latest commit with:
|
This fixed it running
and output this in the Substrate Contracts Node terminal tab
running
and this in the Substrate Contracts Node terminal tab
|
Ok so TLDR, it works now? |
yes thanks working now! i think the telemetry issue might need to be looked into since the error seems to be re-producable, so i've suggested they re-open this issue paritytech/substrate-telemetry#471 (comment) |
In this repo https://github.com/ltfschoen/InkTest I've created my own custom Dockerfile using the relevant ones at https://github.com/paritytech/scripts/blob/master/dockerfiles so I can build with ink! in a Docker container using Linux.
I followed the steps shown in my README up to this step https://github.com/ltfschoen/InkTest/blame/main/README.md#L68 where I ran
cargo contract upload --suri //Alice
.But in Terminal 1 where I was running the Substrate Contracts Node,
Substrate Contracts Node version 0.25.0-a2b09462c7c
it output the following error:And in Terminal 2 where I ran the command
cargo contract upload --suri //Alice
it output the following:Then if I try its recommendation and run it with
--execute
it outputs:But it doesn't seem to have worked, because if i then run
It outputs
ERROR: Expected a bool value
How may I work out what is causing the transport error?
I also realised at that stage that the node wasn't generating or finalising any blocks even though I'm running it with the
--dev
option. I think that's because in the Substrate Contract Node README they mention "The consensus algorithm has been switched to manual-seal ... blocks are authored immediately at every transaction, so there is none of the typical six seconds block time associated with grandpa or aura.". Also mentioned hereWhen I restarted the node I noticed a notification in VSCode that said
"Your application running on port 9615 is available. See all forwarded ports"
, so it's a long shot but it might be because I haven't exposed port 9615 in the Docker container for Prometheus, but I thought that was just to allow for monitoring the node.And if I go to https://contracts-ui.substrate.io/?rpc=ws://127.0.0.1:9944, it displays error `Could not connect to ws://127.0.0.1:9944 Make sure you are running a local substrate-contracts-node 'substrate-contracts-node --dev'.
I think the telemetry error might be because I haven't exposed port 443 in the Docker container.
But I doubt that's related to the WS transport error.
I tried running
cargo contract upload --suri //Alice
again later and it output the following without any error:and when I executed it with
cargo contract upload --suri //Alice --execute
it generated a block and output:The text was updated successfully, but these errors were encountered: