fix: fix E2E test failures in Ink contracts

[0xf333]

Description

The e2e-tests for ink contracts were failing due to an issue with port parsing. This PR introduces:

• tokio::task::spawn_blocking to offload the task to a separate thread.
• std::sync::mpsc channel to efficiently relay the extracted port information.
• Continuous reading of process output to prevent any potential blockages.

---

What This Enables

You can now reliably execute e2e-tests for ink contracts.

Impacts

This pull request addresses issue #1875

---

Testing The Implemented Fix

Environment ==> **Linux**

1. Clone this repo:

git clone https://github.com/0xf333/scenario_for_E2E_test_issue

2. Navigate to /scenario_for_E2E_test_issue/test_PR_fix and make substrate-contracts-node and
   env_setup.sh executable

chmod +x substrate-contracts-node env_setup.sh

3. Navigate to /scenario_for_E2E_test_issue/test_PR_fix/flipper:

cd flipper

4. Compile the contract; you need to do this to pull all the necessary dependencies.
   (Wait for the compilation to finish before proceeding to the next step.)

cargo contract build --release

5. Navigate back to the test_PR_fix directory:

cd ..

6. Run the env_setup.sh bash script to:
   • Set the CONTRACTS_NODE environment variable.
   • Get the path to the crate file where you need to apply this PR fix.
   • Get the path string required to accordingly set ink_e2e inside
     the Cargo.toml file in order to test this PR fix.

source env_setup.sh

Note: Make sure to use source instead of ./ to ensure the CONTRACTS_NODE environment variable is properly set.

7. Copy and paste the changes from this PR into the .rs file ( you'll get the file path after running the bash script ).
   Save the change and then go back to the flipper directory, and run these commands in the same order:

cargo clean

cargo cargo contract build --release

cargo test --features e2e-tests

clean to clean the previous build
conrtact build --release to compile the contract and include changes made inside the ink_e2e dependency.
test --features e2e-tests to run the E2E test

Finally, after executing cargo test --features e2e-tests, make sure that the compilation completes entirely. If you encounter an interruption at:

 [2/4] Post processing wasm file
error: custom attribute panicked

Run the command again. Occasionally in Rust, compilation may prematurely exit during heavy CPU load.

---

Result

Before the fix

before.mp4

After the fix

after.mp4

[0xf333]

meant to be a draft, not a PR yet.

[0xf333]

Hi guys, it's now ready for review.

[ascjones]

Looking at your reproduction, in the issue/flipper/Cargo.toml you are using the 4.2.1 released version of ink_e2e on crates.io. This is not compatible with the latest substrate-contracts-node release.

I would bet that if you change that to use ink master then it will resolve the issue without these changes.

Our CI ensures that the master branch can run all E2E tests against the latest substrate-contracts-node

[0xf333]

Looking at your reproduction, in the issue/flipper/Cargo.toml you are using the 4.2.1 released version of ink_e2e on crates.io. This is not compatible with the latest substrate-contracts-node release.

I would bet that if you change that to use ink master then it will resolve the issue without these changes.

Our CI ensures that the master branch can run all E2E tests against the latest substrate-contracts-node

Hi @ascjones,
Thanks for the feedback, this case is present in ink_e2e 4.2.0 too; the reason I used 4.2.1 is that I thought it would make more sense to solve it in the latest version of ink_e2e rather than in an older one.
Please let me know what you think.

[ascjones]

Looking at your reproduction, in the issue/flipper/Cargo.toml you are using the 4.2.1 released version of ink_e2e on crates.io. This is not compatible with the latest substrate-contracts-node release.
I would bet that if you change that to use ink master then it will resolve the issue without these changes.
Our CI ensures that the master branch can run all E2E tests against the latest substrate-contracts-node

Hi @ascjones, Thanks for the feedback, this case is present in ink_e2e 4.2.0 too; the reason I used 4.2.1 is that I thought it would make more sense to solve it in the latest version of ink_e2e rather than in an older one. Please let me know what you think.

None of the crates.io releases 4.2.0, 4.2.1, or any others are compatible with the latest substrate-contracts-node, because they were released before the node was updated. They will only work with an older version of substrate-contracts-node, and have already been released so can't be changed.

The ink! master branch is already compatible with the latest substrate-contracts-node: you can prove it by navigating to any integration_tests example and running the e2e tests (this is also checked by a CI step).

If you want to use e2e tests with any of the released ink_e2e versions, then use an older release of substrate-contracts-node

If you want to use the latest substrate-contracts-node (which you are doing) then use the ink master branch via a git dependency.

Thank you for the detailed report and reproduction steps, but I don't think these changes are required.

[0xf333]

None of the crates.io releases 4.2.0, 4.2.1, or any others are compatible with the latest substrate-contracts-node, because they were released before the node was updated. They will only work with an older version of substrate-contracts-node, and have already been released so can't be changed.

The ink! master branch is already compatible with the latest substrate-contracts-node: you can prove it by navigating to any integration_tests example and running the e2e tests (this is also checked by a CI step).

If you want to use e2e tests with any of the released ink_e2e versions, then use an older release of substrate-contracts-node

If you want to use the latest substrate-contracts-node (which you are doing) then use the ink master branch via a git dependency.

Thank you for the detailed report and reproduction steps, but I don't think these changes are required.

Hi @ascjones,
Thanks for the feedback.

[ascjones]

@0xf333 we are considering a 4.x release with a backport to fix this issue. Stay tuned.

[0xf333]

@0xf333 we are considering a 4.x release with a backport to fix this issue. Stay tuned.

Hi @ascjones , I sent you an email, please check and let me know.

[ascjones]

See #1884 for backport of fix, will do another 4.x.x series release soon