Return TxId when error in checking of transactions

[AurelienFT]

When we try to turn a Tx in a Checked<Tx>, errors can happens, but we always start by computing the TxId and this can never fails. If something else, fails afterwards it's super useful to have the TxId to link the error with the transaction associated.

Currently, in the existing code calling into_checked(), if we have an error we are computing the TxId ourself again to link it to the CheckError which creates a double computation.

Breaking change

The TxId is now returned with the error.

Before :

fn into_checked(
        self,
        block_height: BlockHeight,
        consensus_params: &ConsensusParameters,
    ) -> Result<Checked<Self>, CheckError>

fn precompute(&mut self, chain_id: &ChainId) -> Result<(), ValidityError>;

Now :

fn into_checked(
        self,
        block_height: BlockHeight,
        consensus_params: &ConsensusParameters,
    ) -> Result<Checked<Self>, (TxId, CheckError)>

fn precompute(&mut self, chain_id: &ChainId) -> Result<(), (TxId, ValidityError)>;

Breaking change notes

I didn't placed this behind a feature flag because I think it's always valuable, however if we want to avoid breaking for now and have this information under a special feature I'm ok with this. Inputs from reviewers would be super valuable on that.

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• If performance characteristic of an instruction change, update gas costs as well or make a follow-up PR for that
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

• Rust SDK : Might be impacted by the change on precompute : https://github.com/FuelLabs/fuels-rs/blob/66b3f0f28817b55b5ff375d5ded1a5b5b400b7ed/packages/fuels-core/src/types/wrappers/transaction.rs#L458

Copilot reviewed 5 out of 11 changed files in this pull request and generated no comments.

Files not reviewed (6)

• fuel-tx/src/transaction/types/blob.rs: Evaluated as low risk
• fuel-tx/src/transaction/types/create.rs: Evaluated as low risk
• fuel-tx/src/transaction/types/mint.rs: Evaluated as low risk
• fuel-tx/src/transaction/types/script.rs: Evaluated as low risk
• fuel-tx/src/transaction/types/upload.rs: Evaluated as low risk
• fuel-vm/src/checked_transaction.rs: Evaluated as low risk

Comments suppressed due to low confidence (3)

fuel-tx/src/transaction/types/upgrade.rs:16

• The error should return (TxId, ValidityError) instead of just ValidityError to match the new error handling pattern.

Err(ValidityError::TransactionUpgradeConsensusParametersChecksumMismatch)?;

fuel-vm/src/tests/upload.rs:280

• The error message should be updated to reflect the new return type, ensuring clarity and consistency.

.expect_err("Should fail to generate checked tx")

fuel-vm/src/tests/upload.rs:307

• The error message should be updated to reflect the new return type, ensuring clarity and consistency.

.expect_err("Should fail to generate checked tx")

[xgreenx]

It would be nice to make this change non breaking. I tried to play with generics, but it still produces breaking code in some cases: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=5f70213c55d0cf6e17abf2cd3e5f17fe

Alternative solution will be to add one more function like into_checked_basic_with_metadata and this one will return metadata in the case of error.

[AurelienFT]

I improved your playground code to be more close to reality and I have something that is breaking only because you need to specify the error type. I don't know if we can still consider this breaking I think so but I would like to have your thoughts. Link : https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d256580f356615cd7ff3979bcd2e3706

[xgreenx]

Yeah, it is why I'm saying it is not good solution because it is still breaking=D So because of that I'm more in favor of the into_checked_basic_with_metadata

[AurelienFT]

Yeah, it is why I'm saying it is not good solution because it is still breaking=D So because of that I'm more in favor of the into_checked_basic_with_metadata

Okey will do that but it will be into_checked_basic_with_id because it's only the id that we have the metadata creation is finished after some error could have been triggered
and precdompute will still breaks, but it's fine i think