FuelLabs/fuels-ts · error · FuelError

UNSUPPORTED_TRANSACTION_TYPE

UNSUPPORTED_TRANSACTION_TYPE

Error message

Unsupported transaction type: ${transactionType}.

What it means

Thrown by `getTransactionTypeName()` (transaction-summary/operations.ts) when mapping a numeric `TransactionType` to a `TransactionTypeName` and the value does not match any known case (Mint, Create, Script, Blob, Upgrade, Upload). The default branch rejects unknown numeric types so summary code never operates on an undefined name.

Source

Thrown at packages/account/src/providers/transaction-summary/operations.ts:80

 * @param transactionType - The transaction type enum value.
 * @returns The transaction type's name.
 */
export function getTransactionTypeName(transactionType: TransactionType): TransactionTypeName {
  switch (transactionType) {
    case TransactionType.Mint:
      return TransactionTypeName.Mint;
    case TransactionType.Create:
      return TransactionTypeName.Create;
    case TransactionType.Script:
      return TransactionTypeName.Script;
    case TransactionType.Blob:
      return TransactionTypeName.Blob;
    case TransactionType.Upgrade:
      return TransactionTypeName.Upgrade;
    case TransactionType.Upload:
      return TransactionTypeName.Upload;
    default:
      throw new FuelError(
        ErrorCode.UNSUPPORTED_TRANSACTION_TYPE,
        `Unsupported transaction type: ${transactionType}.`
      );
  }
}

/** @hidden */
export function isType(transactionType: TransactionType, type: TransactionTypeName) {
  const txType = getTransactionTypeName(transactionType);

  return txType === type;
}

/** @hidden */
export function isTypeMint(transactionType: TransactionType) {
  return isType(transactionType, TransactionTypeName.Mint);
}

View on GitHub (pinned to b3f37c91ac)

Solutions

  1. Upgrade @fuel-ts packages to a version that supports the transaction type returned by the node.
  2. Filter or skip transactions with unknown types before summary assembly.
  3. Report the unknown type value to the SDK maintainers if it persists on a current version.

Example fix

// before
const name = getTransactionTypeName(99); // throws
// after
import { TransactionType } from '@fuel-ts/transactions';
if (tx.type <= TransactionType.Upload) {
  const name = getTransactionTypeName(tx.type);
} else {
  // skip unsupported / unknown tx type
}
Defensive patterns

Strategy: validation

Validate before calling

import { TransactionType } from '@fuel-ts/transactions';
const SUPPORTED = [TransactionType.Mint, TransactionType.Create, TransactionType.Script, TransactionType.Blob, TransactionType.Upgrade, TransactionType.Upload];
if (!SUPPORTED.includes(txType)) throw new Error(`unsupported tx type ${txType}`);

Type guard

function isSupportedTransactionType(t: unknown): t is import('@fuel-ts/transactions').TransactionType {
  return typeof t === 'number' && t >= 0 && t <= TransactionType.Upload;
}

Try / catch

null

Prevention

When it happens

Trigger: Calling `getTransactionTypeName()` / `isType()` (which depends on it) with a transaction type outside the enum. Reached when building a transaction summary for a transaction whose type discriminator is unrecognized.

Common situations: SDK version mismatch where the node returns a transaction type the client SDK does not yet know (e.g. a new tx type shipped on-chain before the SDK supported it); corrupted transaction payload with a bad type byte.

Related errors


AI-assisted analysis of FuelLabs/fuels-ts@b3f37c91ac (2026-08-12). Data as JSON: /api/errors/e6fb53466f69d738. Report an issue: GitHub.