feat: added support for unknown txn types

[maschad]

• Closes Handle unknown tx variants gracefully #2924
• Related to Handle unknown transaction variants gracefully (consensus params, tx types, block headers) fuels-rs#1477

Release notes

In this release, we:

• Added future-proofing to fail gracefully for different transaction types which may exist later on.

Summary

This PR introduces a console.warn for transaction types which the SDK may not support yet. I've made an assumption about what a BaseTransactionType would contain as to distinguish it from a completely unsupported transaction.

Checklist

• All changes are covered by tests (or not applicable)
• All changes are documented (or not applicable)
• I reviewed the entire PR myself (preferably, on GH UI)
• I described all Breaking Changes (or there's none)

[danielbate]

Potentially I'm missing something but I'm not sure we need to treat this in the same way as other transaction types, with a request class and encoding. 🤔

[maschad]

Potentially I'm missing something but I'm not sure we need to treat this in the same way as other transaction types, with a request class and encoding. 🤔

You make a good point re: enconding / decoding @danielbate so I agree with you there, but I disagree re: the request class.

Here's my rationale (which I tried to allude to in the PR description)

The impetus for this PR is for consumers sending transactions to have graceful failures, so therefore an UnknownTransaction is a type of transaction which is not yet supported, and thus it should have at least the base qualities of a transaction with some new / unsupported properties (as opposed to a completely unsupported transaction which would result in an error).

For that reason, and to avoid breaking types in the responses that consumers work with, it needs to be treated as a TransactionRequestLike class instance so that it can be treated as a TransactionResponse otherwise the behaviour would be the same as throwing an error.

Perhaps there may be another way to achieve the same result but I believe this most minimal way to do so, open to hearing your and other peoples thoughts. cc @arboleya @Torres-ssf

[Torres-ssf]

Perhaps there may be another way to achieve the same result but I believe this most minimal way to do so, open to hearing your and other peoples thoughts. cc @arboleya @Torres-ssf

@maschad, I believe a minimal solution for this issue would involve addressing three key methods: Provider.getTransaction, Provider.getTransactions, and TransactionResponse.create.

1 - TransactionResponse.create

This is the most complex part. A user could potentially call it like this:

const response = await TransactionReponse.create(idFromUnsupportedTx)

We could add a try/catch block during the decoding to handle any errors. However, things become tricky afterward, as we can't simply throw the error—we still need to return a return a transaction result with TX summary, just like any other regular transaction.

This might be where we need to introduce a TransactionUnsupported:

export type TransactionUnsupported = {
  type: TransactionType.Unsupported;

  // TX Bytes
  bytes: UInt8Array
};

This type might be necessary because the transaction property is required here. Most other properties can be either booleans (defaulting to false), empty arrays, or values extracted from the receipts.

2 - getTransactions:

Since this method returns an array of transactions, we could simply log a warning and skip unsupported types, or alternatively, return them as TransactionUnsupported.

3 - getTransaction

This method returns a single transaction object. We could return a TransactionUnsupported here. If not, it's unclear to me what else we could return in this case.

[petertonysmith94]

Does this PR address the following:

New input or output types (i.e CoinInputV2)
New opcodes w/ brand new gas price in the consensus params

Or do we already handle these?

[petertonysmith94]

@petertonysmith94 we will not have to handle these as we are not decoding the transaction in it's entirety once it begins with the UNKNOWN type

We call getBaseTransaction within the UnknownTransactionRequest.

fuels-ts/packages/account/src/providers/transaction-request/unknown-transaction-request.ts

Lines 51 to 57 in e7daa05

	toTransaction(): TransactionUnknown {
	return {
	...this.getBaseTransaction(),
	type: TransactionType.Unknown,
	bytes: this.bytes,
	};
	}

This performs inputlify and outputlify on all the inputs and outputs (respectively) of that request.

fuels-ts/packages/account/src/providers/transaction-request/transaction-request.ts

Lines 178 to 179 in e7daa05

	const inputs = this.inputs?.map(inputify) ?? [];
	const outputs = this.outputs?.map(outputify) ?? [];

We throw an error within these functions when the InputType and OutputType are not known. If there was to be a new input or output type (i.e CoinInputV2), would this not throw an error?

[maschad]

We throw an error within these functions when the InputType and OutputType are not known. If there was to be a new input or output type (i.e CoinInputV2), would this not throw an error?

My apologies I should have been more explicit, the context of this PR is that should a consumer try to send or retrieve a transaction that is currently not supported that it will fail gracefully. Those methods handle this error that would be thrown as discussed here

The only scenario someone could call toTransaction on an UnknownTransactionRequest type without interacting with those methods would be if they instantiated the class explicitly, in which case they would correctly have those errors thrown.

[maschad]

After discussing with @Torres-ssf and @petertonysmith94 on a call, we decided it's best to remove the UNKNOWN txn type as it's major use case would be for sending transactions, particularly batch transactions. This would perhaps be unideal as those transactions may have interdependence, in which case, it would not be advisable to submit some of the transactions excluding the unsupported ones.

The PR has now been updated to handle the scenario where we are unable to decode a transaction hash when calling getTransaction or getTransactions , and thus it logs a warning and returns a null response.

[danielbate]

Nice changes 👍🏻

[arboleya]

Clean! 🎯

[github-actions]

Coverage Report:

Lines	Branches	Functions	Statements
79.55%(+0.13%)	71.91%(+0.05%)	78%(+0.3%)	79.68%(+0.13%)

Changed Files:

Ok	File (✨=New File)	Lines	Branches	Functions	Statements
🔴	packages/account/src/providers/provider.ts	70.46% (+2.46%)	61.65% (+1.11%)	76.19% (+3.91%)	70.37% (+2.41%)
🔴	packages/account/src/providers/generated/operations.ts	95.65% (+1.45%)	100% (+0%)	86.36% (+4.55%)	96.02% (+1.32%)