spl-associated-token-account v1.0.4 regression

[armaniferrante]

I'm short on details but there appears to be a regression in v1.0.4 of the spl-associated-token-account crate, where a Program ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL failed: insufficient account keys for instruction error is returned when trying to initialize an account on solana-test-validator. This error goes away when pinning to v1.0.3.

[CriesofCarrots]

cc @joncinque , I assume your monorepo PRs will resolve this?

[joncinque]

Sorry about that -- yeah you'll have to pin until 1.0.4 is released to mainnet and solana-labs/solana#22649 is integrated. We're kind of caught between two bad situations, either:

• that PR gets merged, people start developing against that. If they launch to mainnet against 1.0.4, and the new program hasn't been released, then they'll get failures that they couldn't see while developing
• don't merge the PR, and people have to pin to 1.0.3 for now

I'm happy to do either, but the second option sounded better. We could also yank the crate to avoid the issue, but we also have new stuff in ATA, so we'd have to revert those changes to re-release the crate.

[mvines]

We should yank 1.0.4, it's broken.

To fix, 1.0.5 can revert create_associated_token_account() back to its original form that accepts the rent sysvar:
https://github.com/solana-labs/solana-program-library/blob/associated-token-account-v1.0.3/associated-token-account/program/src/lib.rs#L68-L89

Users can then select the non-rent sysvar version by updating their code to use instruction::create_associated_token_account()

[joncinque]

Crate was yanked: https://crates.io/crates/spl-associated-token-account/versions

Users can then select the non-rent sysvar version by updating their code to use instruction::create_associated_token_account()

Yeah, this'll make a lot more sense