FuelLabs/fuels-ts · error · FuelError

UNSUPPORTED_TRANSACTION_TYPE

UNSUPPORTED_TRANSACTION_TYPE

Error message

Unsupported transaction type: ${type}.

What it means

Thrown by `transactionRequestify(obj)` (utils.ts) when the object's `type` is not one of the known `TransactionType` values (Script, Create, Blob, Upgrade, Upload). The factory switches on the discriminator to pick the correct request subclass; the default branch rejects anything unrecognized so an invalid type does not silently produce a wrong subclass.

Source

Thrown at packages/account/src/providers/transaction-request/utils.ts:42

  switch (obj.type) {
    case TransactionType.Script: {
      return ScriptTransactionRequest.from(obj);
    }
    case TransactionType.Create: {
      return CreateTransactionRequest.from(obj);
    }
    case TransactionType.Blob: {
      return BlobTransactionRequest.from(obj);
    }
    case TransactionType.Upgrade: {
      return UpgradeTransactionRequest.from(obj);
    }
    case TransactionType.Upload: {
      return UploadTransactionRequest.from(obj);
    }
    default: {
      throw new FuelError(
        ErrorCode.UNSUPPORTED_TRANSACTION_TYPE,
        `Unsupported transaction type: ${type}.`
      );
    }
  }
};

/** @hidden */
export const isTransactionTypeScript = (
  request: TransactionRequestLike
): request is ScriptTransactionRequest => request.type === TransactionType.Script;

/** @hidden */
export const isTransactionTypeCreate = (
  request: TransactionRequestLike
): request is CreateTransactionRequest => request.type === TransactionType.Create;

/** @hidden */

View on GitHub (pinned to b3f37c91ac)

Solutions

  1. Ensure the object passed to `transactionRequestify` has a valid `type` from TransactionType (Script=0, Create=1, Blob=2, Upgrade=3, Upload=4).
  2. Prefer constructing requests with the concrete subclass constructors (ScriptTransactionRequest, CreateTransactionRequest, etc.) which set the type internally.
  3. Round-trip test serialization/deserialization to confirm the `type` survives persistence.

Example fix

// before
const req = transactionRequestify({ gasLimit: 1000, script: '0x...' }); // no type
// after
import { TransactionType } from '@fuel-ts/transactions';
const req = transactionRequestify({
  type: TransactionType.Script,
  gasLimit: 1000,
  script: '0x...',
});
Defensive patterns

Strategy: type-guard

Validate before calling

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

Type guard

function isTransactionRequestLike(v: unknown): v is import('@fuel-ts/transactions').TransactionRequestLike {
  return typeof v === 'object' && v !== null && 'type' in v &&
    [0,1,2,3,4].includes((v as any).type);
}

Try / catch

null

Prevention

When it happens

Trigger: Calling `transactionRequestify()` or `TransactionRequest.from()` on an object whose `type` is missing, numeric value outside the enum, or a string. This helper is the generic deserialization entry point from plain objects.

Common situations: Restoring a transaction from persisted JSON that lost the `type` field; cross-version deserialization where TransactionType enum values changed; passing a partially-built request object that was never assigned a type.

Related errors


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