1

Using a local validator to run some tests against the Squads v4 program, and encountering issues when confirming transactions.

The file in question can be found here: https://github.com/Squads-Protocol/v4-examples/blob/main/typescript/main.ts

Requires the test validator be loaded with the following:

solana-test-validator --url m -c SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf -c BSTq9w3kZwNwpBXJEvTZz2G9ZTNyKBvoSeXMvwb4cNZr -c Fy3YMJCvwbAXUgUM5b91ucUVA3jYzwWLHL3MwBqKsh8n

Test 1 fails when confirming the "multisigCreateV2" transaction with the method shown in the file (deprecated version) and the following:

console.log("Confirming Transaction...");
const block = await connection.getLatestBlockhash("confirmed");
    
const result = await connection.confirmTransaction(
  {
   signature,
   ...block,
  },
  "confirmed",
);

const error = result.value.err;
if (error) {
  throw Error(error.toString());
}

With either method, the confirmation will timeout in 30 seconds, or throw a block height exceeded error. The previous airdrop will work fine with a fresh ledger (also using deprecated "confirmTransaction"), but will also sometimes throw a timeout with a previous test-ledger. From previous local testing on other programs, this process usually happens nearly instantly.

For reference, I've tried using CLI versions starting from 1.17.18 up to the current release. Also currently running on a M1 Mac w/ 12.7.2, but had the same issue on Windows 11 using WSL. Can provide any logs needed to help further understand the situation.

Can anyone else reproduce on their end?

2
  • This happens with all transactions or only this test? Trying to understand if it's a local validator problem or something else. There was an issue with local validator being slow before github.com/anza-xyz/agave/pull/716, but we should be fine now
    – Jacob Creech
    Commented Apr 16 at 15:27
  • I haven't attempted with another custom program yet, but confirming airdrops seems to work fine. The other tests are dependent on the first test, so I can't test those as is
    – Joey Meere
    Commented Apr 16 at 23:41

1 Answer 1

2

This is a subtle issue.

You're cloning the program SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf and its program-data account Fy3YMJCvwbAXUgUM5b91ucUVA3jYzwWLHL3MwBqKsh8n directly, which won't work. The program-data account contains a field for the "last deployed slot", which tells the runtime "do not run this program until we've reached one slot past this slot".

You can check that by running:

$ solana -ul program show SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf

Program Id: SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: Fy3YMJCvwbAXUgUM5b91ucUVA3jYzwWLHL3MwBqKsh8n
Authority: 3YNUB5PLxpC3iNK7C5PeeX1CZySPMPTpPiPzTf9DBxbe
Last Deployed In Slot: 244446274
Data Length: 1470416 (0x166fd0) bytes
Balance: 10.23529944 SOL

You've copied this straight from mainnet, which will have a high last deployed slot, to your test validator, which just started on slot 0. So you'll need to wait a very long time before your test validator can run the program.

To get around this, just use the --clone-upgradeable-program flag with 1.18.10, ie:

solana-test-validator --url m --clone-upgradeable-program SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf -c BSTq9w3kZwNwpBXJEvTZz2G9ZTNyKBvoSeXMvwb4cNZr

To get:

$ solana -ul program show SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf

Program Id: SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: Fy3YMJCvwbAXUgUM5b91ucUVA3jYzwWLHL3MwBqKsh8n
Authority: 3YNUB5PLxpC3iNK7C5PeeX1CZySPMPTpPiPzTf9DBxbe
Last Deployed In Slot: 0
Data Length: 1470416 (0x166fd0) bytes
Balance: 10.23529944 SOL
1
  • Thanks for the clarification!
    – Joey Meere
    Commented Apr 20 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.