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
- Ensure the object passed to `transactionRequestify` has a valid `type` from TransactionType (Script=0, Create=1, Blob=2, Upgrade=3, Upload=4).
- Prefer constructing requests with the concrete subclass constructors (ScriptTransactionRequest, CreateTransactionRequest, etc.) which set the type internally.
- 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
- Prefer concrete subclass constructors over transactionRequestify for new requests.
- Round-trip test serialization to confirm the type field survives.
- Validate persisted JSON before deserializing.
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
- INVALID_TRANSACTION_INPUT
- INVALID_TRANSACTION_INPUT
- Witness at index "${index}" was not found
- NOT_IMPLEMENTED
- UNSUPPORTED_TRANSACTION_TYPE
AI-assisted analysis of FuelLabs/fuels-ts@b3f37c91ac (2026-08-12).
Data as JSON: /api/errors/f08275d0dce16f8f.
Report an issue: GitHub.