feat(multichain-account-service): add option to decide what to await for when creating group

[mathieuartu]

Explanation

- Add an optional `options` parameter to `MultichainAccountWallet.createMultichainAccountGroup()`
  - Introduces `options.waitForAllProvidersToFinishCreatingAccounts`, that will make `createMultichainAccountGroup` await either only the EVM provider or all the providers to have created their accounts depending on the value. Defaults to `false` (only awaits for EVM accounts creation by default).

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

---

Note

Adds an options.waitForAllProvidersToFinishCreatingAccounts flag to createMultichainAccountGroup, defaulting to awaiting only EVM, and updates createNextMultichainAccountGroup to await all.

• Multichain Account Service:
  • createMultichainAccountGroup:
    • Add optional options with waitForAllProvidersToFinishCreatingAccounts (default false).
    • If true: await all providers via Promise.allSettled; throw on any failure with aggregated warnings.
    • If false (default): await EVM provider; start other providers in background, log but ignore their errors.
    • Update JSDoc for parameters and error semantics.
  • createNextMultichainAccountGroup: now calls createMultichainAccountGroup with waitForAllProvidersToFinishCreatingAccounts: true.
  • Tests: add coverage for failure when waiting for all providers; adjust non-EVM background behavior test.
  • Changelog: document new options parameter and behavior.

^{Written by Cursor Bugbot for commit 403d744. This will update automatically on new commits. Configure here.}

[ccharly]

LGTM

[fabiobozzo]

Does that assume EVM provider is always first? Can't the provider order change in theory?

[fabiobozzo]

const evmProvider = this.#providers.find(p => p instanceof EvmAccountProvider);
assert(evmProvider, 'EVM account provider not found');
const otherProviders = this.#providers.filter(p => p !== evmProvider);

Maybe overkill 😋

[ccharly]

That's not needed IMO. We could have an extra assert after we build the list of providers to enforce this precondition (like EVM provider always comes first)

[fabiobozzo]

This is a breaking change isn't it? Do we have to point that out in changelog? 👀

[ccharly]

Last change we made around this method was also altering the behavior a bit, but we did not treat it as a breaking change either.

I think, it could be seen as such, but for now, the only guarantee that we have for the multichain account group is that we ALWAYS HAVE at least an EVM account, and that still holds true with the previous change we made AND this one IMO.

Lastly, for simplicity, I would like to avoid breaking change in those packages to avoid bubbling up to other dependents controllers (we need this fix to be merged ASAP).

If we change our mind, we'll make a new 2.0.0 and amend the changelog if really needed later!

[fabiobozzo]

This case only uses 1 provider but claims to test "all providers" behavior, do I read that right? Should it use multiple providers to properly test instead?

[ccharly]

It does claim that "if any of the provider fails", so the test is ok.

Though, I think we could have used the scenario EVM + Solana provider where Solana fails, that could have been clearer indeed 👍

[fabiobozzo]

Shouldn't we track background promises too? Or is it the meaning to ignore failures here and future alignments will fix it? or do I miss something? 🤔

[mathieuartu]

Yes exactly, we willingly ignore failures for providers creating accounts in the background

[ccharly]

Yes that's expected to not throw in that case, mostly because would not be any way to catch them truly

Though, we make sure the EvmAccountProvider is successful.

If any of the other providers fail, then yes we would need an alignment for this (unfortunately, we don't have any state to tell us a group is misaligned for now, and we might need that in the near future IMO)

[fabiobozzo]

LGTM. @mathieuartu I left a couple comments as food for thoughts, no remarks