ci: wait for 3 blocks before starting contract #10295
Conversation
rabi-siddique
force-pushed
the
rs-fix-getting-started-flakes
branch
from
c994205
to
12097bc
Compare
Deploying agoric-sdk with
|
| Latest commit: |
10ee3d4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://8a410b03.agoric-sdk.pages.dev |
| Branch Preview URL: | https://rs-fix-getting-started-flake.agoric-sdk.pages.dev |
rabi-siddique
changed the title
mujahidkay
force-pushed
the
rs-fix-getting-started-flakes
branch
from
551b69e
to
2b0dc3a
Compare
mujahidkay
changed the title
mujahidkay
force-pushed
the
rs-fix-getting-started-flakes
branch
from
2b0dc3a
to
10ee3d4
Compare
mujahidkay
changed the title
| if (earlierHeight > 0n && currentHeight > earlierHeight) { | ||
| // We've had at least one block produced. | ||
| if (earlierHeight > 2n && currentHeight > earlierHeight) { | ||
| // We've had at least 3 blocks produced. |
There was a problem hiding this comment.
How is waiting for three blocks fix the account seq mismatch issue? Isn't it due to parallel jobs doing tx with same account?
There was a problem hiding this comment.
How is waiting for three blocks fix the account seq mismatch issue?
As per my inspection, the initial blocks often contain transactions from governance-related wallets when the chain starts. Starting the contract also involves these governance wallets. When these transactions overlap during the initial blocks, it can lead to an account sequence mismatch. Since we now wait for three blocks to be produced, this should be sufficient to surpass the phase where governance wallets are involved in transactions.
Isn't it due to parallel jobs doing tx with same account?
No. Each getting-started job runs independently in its own runner. There's no shared state between workflows, as each one runs its own A3P chain in a separate space.
There was a problem hiding this comment.
Hmm right. So As far as I know, this tx sequence is linked with account/wallet as well. Our tests use user1 (install-bundles.sh), so about governance wallet transactions, their sequence number shouldn't disturb user1, right? Not sure just thnking out loud.
There was a problem hiding this comment.
user1 is involved in installing bundles. But for the contract core eval to be passed, I reckon governance wallets take part in it via voting on it. I think that phase leads to account sequence mismatch.
There was a problem hiding this comment.
Hmmm interesting.
So do we have successful re-runs as well?
There was a problem hiding this comment.
Yes. Mujahid and I ran it several times. Did not encounter any flakes or failures.
There was a problem hiding this comment.
There was a problem hiding this comment.
Good possible detection.
Can you also update PR description with
#10295 (comment)?
Also I see we did multiple runs with successful outcome 🤞❤️
rabi-siddique
added
the
automerge:rebase
closes: #9325
Description
As per my inspection, the initial blocks often contain transactions from governance-related wallets when the chain starts. Starting the contract also involves these governance wallets. When these transactions overlap during the initial blocks, it can lead to an account sequence mismatch. Since we now wait for three blocks to be produced, this should be sufficient to surpass the phase where governance wallets are involved in transactions.
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations