fix: improve solana speed tests#111
Conversation
Release impact (release-please)
PR title: Merging this PR as-is will contribute a patch bump to the next release-please release PR. Conventional commit → bump
Update the PR title before merge if you need a different bump (squash commit message = PR title). Preview is based on this PR title only. The release-please release PR may include other unreleased commits already on |
Cache MCMS program artifacts once per process, fix PreloadMCMS nested-subtest deadlocks, use a mock env for set-config VerifyPreconditions, and reuse an existing chain in fund-mcm-pdas instead of starting a second validator.
ecPablo
force-pushed
the
ecpablo/solana-test-speed
branch
from
63797fa to
e07b5ca
Compare
|
| progIDs := loadProgramArtifacts(t, | ||
| solutils.MCMSProgramNames, downloadChainlinkCCIPProgramArtifacts, dir, | ||
| ) | ||
| func acquireSolanaTestIsolation(t *testing.T) { |
There was a problem hiding this comment.
I confess I don't get how this lock works...
There was a problem hiding this comment.
here's how I'm reading it: it allows the same t instance to call PreloadMCMS multiple times, without locking. Any other calls will wait. Is that the idea? How often do we call PreloadMCMS this way?
There was a problem hiding this comment.
It's more a process wide lock the idea is to mainly serialize the calls to SetProgramID which is what bites us when running these tests with t.Parallel()
Should work something like this:
- First,
PreloadMCMS()call while solTestDepth == 0 acquires solTestExclusive. - Then Every
PreloadMCMScall increments depth and registers at.Cleanupon that test’st. - Nested calls see depth > 0, skip re-locking, and only bump depth to deadlock.
- Unlock happens only when the outermost cleanup runs (depth back to 0), i.e. when the whole nested stack of tests that called PreloadMCMS has finished.
2 participants
Reuse some of the containers to speed up tests for solana