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

ltfschoen · 2023-05-10T20:24:48Z

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:

...
WARN tokio-runtime-worker telemetry: ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout } 
...
2023-05-10 18:28:43.609  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xac6a…5c4f), finalized #0 (0xac6a…5c4f), ⬇ 0 ⬆ 0    
2023-05-10 18:28:44.188 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-10 18:28:47.088 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-10 18:28:47.088  INFO tokio-runtime-worker jsonrpsee_server::server: Accepting new connection 1/100
2023-05-10 18:28:47.967  INFO tokio-runtime-worker jsonrpsee_server::server: Accepting new connection 2/100
2023-05-10 18:28:48.086 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
2023-05-10 18:28:48.589  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xac6a…5c4f), finalized #0 (0xac6a…5c4f), ⬇ 0 ⬆ 0    
2023-05-10 18:28:49.973 DEBUG tokio-runtime-worker sync: Propagating transactions

And in Terminal 2 where I ran the command cargo contract upload --suri //Alice it output the following:

# cargo contract upload --suri //Alice
      Result Success!
   Code hash "0xa0c52cd7843da761236263923f454d5860db1794855de29396cc9908c58bd4b9"
     Deposit 434790000000
Your upload call has not been executed.
To submit the transaction and execute the call on chain, add -x/--execute flag to the command.

Then if I try its recommendation and run it with --execute it outputs:

cargo contract upload --suri //Alice --execute
      Events
       Event Balances ➜ Withdraw
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         amount: 2.142696855mUNIT
       Event Balances ➜ Reserved
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         amount: 434.79mUNIT
       Event Contracts ➜ CodeStored
         code_hash: 0xa0c52cd7843da761236263923f454d5860db1794855de29396cc9908c58bd4b9
       Event TransactionPayment ➜ TransactionFeePaid
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         actual_fee: 2.142696855mUNIT
         tip: 0UNIT
       Event System ➜ ExtrinsicSuccess
         dispatch_info: DispatchInfo { weight: Weight { ref_time: 2142684257, proof_size: 3574 }, class: Normal, pays_fee: Yes }

   Code hash "0xa0c52cd7843da761236263923f454d5860db1794855de29396cc9908c58bd4b9"

But it doesn't seem to have worked, because if i then run

cargo contract instantiate \
	--suri //Bob \
	--constructor new \
	--args 10

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 here

When 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:

2023-05-10 20:43:22.136  INFO tokio-runtime-worker jsonrpsee_server::server: Accepting new connection 1/100
2023-05-10 20:43:22.174  INFO tokio-runtime-worker jsonrpsee_server::server: Accepting new connection 2/100

and when I executed it with cargo contract upload --suri //Alice --execute it generated a block and output:

2023-05-10 20:44:37.186  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0xac6a…5c4f), finalized #0 (0xac6a…5c4f), ⬇ 0 ⬆ 0    
2023-05-10 20:44:38.836 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-10 20:44:41.736 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-10 20:44:42.055  INFO tokio-runtime-worker jsonrpsee_server::server: Accepting new connection 1/100
2023-05-10 20:44:42.090 DEBUG tokio-runtime-worker sync: Propagating transaction [0xfe35a7db5726c74c87cf87d3fc5c72af47e8ac185bc3f0728991153a6a81b926]    
2023-05-10 20:44:42.086  INFO tokio-runtime-worker sc_basic_authorship::basic_authorship: 🙌 Starting consensus session on top of parent 0xac6a64e8f59e8358d5c1749fd229619fceb4b2e6bd64ac102d64c1608ad75c4f    
2023-05-10 20:44:42.102  INFO tokio-runtime-worker sc_basic_authorship::basic_authorship: 🎁 Prepared block for proposing at 1 (6 ms) [hash: 0xdbf621db3b67d052aa3836e475c031c3e0156e14c5305900857b39aeb40fb029; parent_hash: 0xac6a…5c4f; extrinsics (2): [0xd410…77bf, 0xfe35…b926]]    
2023-05-10 20:44:42.110 DEBUG tokio-runtime-worker sync: Reannouncing block 0xdbf621db3b67d052aa3836e475c031c3e0156e14c5305900857b39aeb40fb029 is_best: true    
2023-05-10 20:44:42.110 DEBUG tokio-runtime-worker sync: New best block imported 0xdbf621db3b67d052aa3836e475c031c3e0156e14c5305900857b39aeb40fb029/#1    
2023-05-10 20:44:42.113  INFO tokio-runtime-worker substrate: ✨ Imported #1 (0xdbf6…b029)    
2023-05-10 20:44:42.116  INFO tokio-runtime-worker sc_consensus_manual_seal::rpc: Instant Seal success: CreatedBlock { hash: 0xdbf621db3b67d052aa3836e475c031c3e0156e14c5305900857b39aeb40fb029, aux: ImportedAux { header_only: false, clear_justification_requests: false, needs_justification: false, bad_justification: false, is_new_best: true } }    
2023-05-10 20:44:42.188  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #1 (0xdbf6…b029), finalized #0 (0xac6a…5c4f), ⬇ 0 ⬆ 0

The text was updated successfully, but these errors were encountered:

ltfschoen · 2023-05-11T02:04:14Z

so i installed netstat with apt-get install -y net-tools, and then when i ran it, these were the only outputs

root@xxx:/app/dapps/mydapp# netstat

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 8cd6f7c6716c:37216      151.101.30.132:80       TIME_WAIT  
tcp        0      0 8cd6f7c6716c:57644      172.67.71.26:443        ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  3      [ ]         STREAM     CONNECTED     501775   
unix  3      [ ]         STREAM     CONNECTED     501776

so i modified the docker-compose.yml file with network_mode: host to just expose all ports so its like running on the host machine https://docs.docker.com/compose/compose-file/compose-file-v3/#network_mode

then when i entered the container's shell it showed a lot more active connections when i ran netstat.
but i still got the same errors when i ran cargo contract upload --suri //Alice

ltfschoen · 2023-05-11T03:13:07Z

Someone else encountered this same error https://substrate.stackexchange.com/questions/7361/ink-contract-upload-error.
Based on the comments there it seems the error may be caused by one of the calls not being compatible with the version of pallet_contracts that i'm using.

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

# substrate-contracts-node --version
substrate-contracts-node 0.25.0-a2b09462c7c

and the Cargo Contracts version used is

cargo contract --version
cargo-contract-contract 2.2.1-7253c6a-x86_64-unknown-linux-gnu

But what confuses me, is that the latest commit of this repo that i'm using 7253c6a, shows that it's using these dependencies:

sp-core = "20.0.0"
sp-keyring = "23.0.0"

whilst the latest commit of https://github.com/paritytech/substrate-contracts-node/blob/main/runtime/Cargo.toml#LL31C119-L31C135 uses

sp-core = { git = "https://github.com/paritytech/substrate", package = "sp-core", default-features = false, branch = "polkadot-v0.9.42" }

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

sp-core = { version = "7.0.0", default-features = false, path = "../../primitives/core" }

So the latest commit of "cargo-contractusessp-core = "20.0.0", but the latest commit of "substrate-contracts-node" and "substrate" repos use sp-core = "7.0.0"`??

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

ltfschoen · 2023-05-11T03:19:27Z

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:

cargo install contracts-node --git https://github.com/paritytech/substrate-contracts-node.git --tag v0.23.0 --force --locked

and install the latest stable version of cargo-contract instead of the latest commit with:

cargo install cargo-contract --version 2.2.1

ltfschoen · 2023-05-11T06:00:02Z

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:
cargo install contracts-node --git https://github.com/paritytech/substrate-contracts-node.git --tag v0.23.0 --force --locked
and install the latest stable version of cargo-contract instead of the latest commit with:
cargo install cargo-contract --version 2.2.1

This fixed it

running cargo contract upload --suri //Alice output:

      Result Success!
   Code hash "0xec3a66a8f99674ecf25d180fc39ee8e620d45e8de459277e353ece20753d6c53"
     Deposit 434925000000
Your upload call has not been executed.
To submit the transaction and execute the call on chain, add -x/--execute flag to the command.

and output this in the Substrate Contracts Node terminal tab

2023-05-11 05:49:47.389  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0x18c5…59af), finalized #0 (0x18c5…59af), ⬇ 0 ⬆ 0    
2023-05-11 05:49:48.124 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-11 05:49:48.437  INFO tokio-runtime-worker jsonrpsee_ws_server::server: Accepting new connection 1/100
2023-05-11 05:49:50.006  INFO tokio-runtime-worker jsonrpsee_ws_server::server: Accepting new connection 2/100
2023-05-11 05:49:51.027 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-11 05:49:52.392  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0x18c5…59af), finalized #0 (0x18c5…59af), ⬇ 0 ⬆ 0

running cargo contract upload --suri //Alice --execute outputs:

      Events
       Event Balances ➜ Withdraw
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         amount: 2.068216063mUNIT
       Event Balances ➜ Reserved
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         amount: 434.925mUNIT
       Event Contracts ➜ CodeStored
         code_hash: 0xec3a66a8f99674ecf25d180fc39ee8e620d45e8de459277e353ece20753d6c53
       Event TransactionPayment ➜ TransactionFeePaid
         who: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
         actual_fee: 2.068216063mUNIT
         tip: 0UNIT
       Event System ➜ ExtrinsicSuccess
         dispatch_info: DispatchInfo { weight: Weight { ref_time: 2068203465, proof_size: 0 }, class: Normal, pays_fee: Yes }

   Code hash "0xec3a66a8f99674ecf25d180fc39ee8e620d45e8de459277e353ece20753d6c53"

and this in the Substrate Contracts Node terminal tab

2023-05-11 05:56:10.582  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0x18c5…59af), finalized #0 (0x18c5…59af), ⬇ 0 ⬆ 0    
2023-05-11 05:56:11.793  INFO tokio-runtime-worker jsonrpsee_ws_server::server: Accepting new connection 1/100
2023-05-11 05:56:11.797 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-11 05:56:13.276 DEBUG tokio-runtime-worker sync: Propagating transaction [0x27855e94096938dcb8a0b54aa6eb10f1c7fc4b6a4691cbe8022218600c8a5b30]    
2023-05-11 05:56:13.320  INFO tokio-runtime-worker sc_basic_authorship::basic_authorship: 🙌 Starting consensus session on top of parent 0x18c5ce867c31a60bfdd97f1cc6656e684370cea155a1556c9340f18d47ac59af    
2023-05-11 05:56:13.960  INFO tokio-runtime-worker sc_basic_authorship::basic_authorship: 🎁 Prepared block for proposing at 1 (431 ms) [hash: 0x9bc460edc15179afa81912948bbb0f537add47434c9dea3a08ef52154165be22; parent_hash: 0x18c5…59af; extrinsics (2): [0xa8a7…4455, 0x2785…5b30]]    
2023-05-11 05:56:14.046 DEBUG tokio-runtime-worker sync: Reannouncing block 0x9bc460edc15179afa81912948bbb0f537add47434c9dea3a08ef52154165be22 is_best: true    
2023-05-11 05:56:14.047 DEBUG tokio-runtime-worker sync: New best block imported 0x9bc460edc15179afa81912948bbb0f537add47434c9dea3a08ef52154165be22/#1    
2023-05-11 05:56:14.053  INFO tokio-runtime-worker sc_consensus_manual_seal::rpc: Instant Seal success: CreatedBlock { hash: 0x9bc460edc15179afa81912948bbb0f537add47434c9dea3a08ef52154165be22, aux: ImportedAux { header_only: false, clear_justification_requests: false, needs_justification: false, bad_justification: false, is_new_best: true } }    
2023-05-11 05:56:14.102  INFO tokio-runtime-worker substrate: ✨ Imported #1 (0x9bc4…be22)    
2023-05-11 05:56:14.699 DEBUG tokio-runtime-worker sync: Propagating transactions    
2023-05-11 05:56:15.591  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #1 (0x9bc4…be22), finalized #0 (0x18c5…59af), ⬇ 0 ⬆ 0

ascjones · 2023-05-11T08:06:45Z

Ok so TLDR, it works now?

ltfschoen · 2023-05-11T09:42:14Z

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)

ltfschoen mentioned this issue May 11, 2023

Situation with docker image #1103

Open

ltfschoen closed this as completed May 11, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ltfschoen commented May 10, 2023 •

edited

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ascjones commented May 11, 2023

ltfschoen commented May 11, 2023

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

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

ltfschoen commented May 10, 2023 • edited

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ltfschoen commented May 11, 2023

ascjones commented May 11, 2023

ltfschoen commented May 11, 2023

ltfschoen commented May 10, 2023 •

edited