Skip to content

Fix Retester Flakiness #540

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.

Sign up for GitHub

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

Merged
0xOmarA merged 3 commits into from
Jun 2, 2026
Merged

Fix Retester Flakiness #540

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2d13d5a
Update the diff tests commit hash
0xOmarA Jun 1, 2026
0cdc20a
Try higher concurrency
0xOmarA Jun 1, 2026
8011b21
Slightly better comment
0xOmarA Jun 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions .github/workflows/differential-tests.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -164,9 +164,9 @@ jobs:
resolc-path: ./resolc-bin/resolc-x86_64-unknown-linux-musl
solc-version: ${{ env.SOLC_VERSION }}
expectations-file-path: ./revive/.github/assets/revive-dev-node-polkavm-resolc.json
# Using a higher concurrency, such as 100, currently overloads the dev node's RPC
# bridge, causing intermittent `eth_getTransactionReceipt` timeouts during code upload.
concurrency-number-of-concurrent-tasks: 50
# Use a sane value which is fast enough to make the tests run fast but not too
# fast that it overwhelms the node.
concurrency-number-of-concurrent-tasks: 1000
Copy link
Copy Markdown
Member

@xermicus xermicus Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you pick this number? On our hardware, is 1000 concurrent tasks actually faster than lets say 100?

Copy link
Copy Markdown
Contributor Author

@0xOmarA 0xOmarA Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's quite arbitrary to be honest, it's more of a trial and error and seeing what's best on the different machines.

Also, yes it does make things faster. https://github.com/paritytech/revive/actions/runs/26739486516/job/78802512016 took 37 minutes to run and this https://github.com/paritytech/revive/actions/runs/26776693394/job/78933925021 took 19 minutes to run so it's a good reduction


# Sentinel job that depends on the jobs we want to allow completing (instead of
# being canceled once the other job chains complete). Thus, run-e2e-tests
Expand Down
2 changes: 1 addition & 1 deletion revive-differential-tests
Open in desktop
Submodule revive-differential-tests updated 7 files
+3 −0 .github/actions/require-binary/action.yaml
+5 −0 .github/actions/setup-benchmark-machine/action.yaml
+26 −4 .github/workflows/benchmark.yaml
+19 −2 crates/node-interaction/src/lib.rs
+3 −2 crates/node/src/lib.rs
+191 −37 crates/node/src/node_implementations/substrate.rs
+1 −1 resolc-compiler-tests
Loading