allow ability to pass in feePayer to Provider methods [WIP]

[surfertas]

Allow passing in an optional feePayer param to the send methods of the Provider class. This allows the caller to specify who pays for the transaction, as opposed to hard coding it to the connected wallet.

closes #2180

Reference discord discussion:

https://discord.com/channels/889577356681945098/891724485177245717/1020066171329982605

[vercel]

@surfertas is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[Henry-E]

Instead of adding a new argument, could the code instead check if feePayer has already been set in the transaction and if not then it assigns the provider's wallet?

If you could also add something to the changelog in the PR that references this PR that would be helpful too.

[Henry-E]

Looks good to me! Will merge it in shortly

[surfertas]

@Henry-E Was wondering if we should be using a strict equality check for undefined or use a null check to handle both cases?

[Henry-E]

In the default transaction it looks like feePayer is actually undefined

    Transaction {
      signatures: [],
      feePayer: undefined,
      instructions: [],
      recentBlockhash: undefined,
      lastValidBlockHeight: undefined,
      nonceInfo: undefined,
      _message: undefined,
      _json: undefined
    }

so you should be checking

if (tx.feePayer === undefined)

You should probably add a client test then to /misc, to send a tx, then load up the processed transaction to confirm that the fee payer was assigned correctly, since it looks like this code probably wouldn't have worked.

[surfertas]

Yeah sounds good, technically the null check will capture undefined as well afiak, but the strict equality check for undefined is more concise! Will put that test up.

[armaniferrante]

Yeah sounds good, technically the null check will capture undefined as well afiak, but the strict equality check for undefined is more concise! Will put that test up.

I'm not sure this is true. We should check for both?

[surfertas]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/null

tx.feePayer == null will handle both null and undefined. Shall we go with that?

[Henry-E]

Sure, if tx.feepayer == null works for both then that should be fine. Just to be safe lets add a client test to tests/misc that sends three transactions

• one transaction with the usual undefined feepayer
• one with a custom fee payer
• one transaction with a feepayer manually set to null
  Then check the transaction signature to confirm that all three have the correct fee payer.

(I might be able to add these tests next week if you aren't able to add them)

[surfertas]

@Henry-E sorry hate to ask, but if you have time can you throw up thoses tests? Just got backed up with work. Sincere apologies.

[Henry-E]

• It's a pretty useful added feature that fixes some over reaching behaviour of the anchor provider. Namely it allows the transaction creator to add their own feePayer which isn't over written by the anchor provider default wallet.
• It doesn't have tests which isn't great but the logic seems simple enough and the logical or || should handle the null case nicely when the feePayer is undefined or null (or 0?).

Just going to wait for tests to run again and then merge.