FuelLabs/fuels-ts · error · FuelError

INVALID_TRANSACTION_INPUT

INVALID_TRANSACTION_INPUT

Error message

Invalid transaction output type: ${type}.

What it means

Thrown by the `outputify` helper when serializing a transaction output whose `type` does not match any known `OutputType` (Coin, Contract, Change, Variable, ContractCreated). Note: the error code is `INVALID_TRANSACTION_INPUT` (a likely copy-paste defect in the SDK; the message correctly says 'output'). The default branch of the switch in output.ts:98 is reached only when the discriminator is unrecognized.

Source

Thrown at packages/account/src/providers/transaction-request/output.ts:99

      };
    }
    case OutputType.Variable: {
      return {
        type: OutputType.Variable,
        to: hexlify(value.to || ZeroBytes32),
        amount: bn(value.amount),
        assetId: hexlify(value.assetId || ZeroBytes32),
      };
    }
    case OutputType.ContractCreated: {
      return {
        type: OutputType.ContractCreated,
        contractId: hexlify(value.contractId),
        stateRoot: hexlify(value.stateRoot),
      };
    }
    default: {
      throw new FuelError(
        ErrorCode.INVALID_TRANSACTION_INPUT,
        `Invalid transaction output type: ${type}.`
      );
    }
  }
};

View on GitHub (pinned to b3f37c91ac)

Solutions

  1. Ensure every output object carries a valid `type` from the OutputType enum (Coin=0, Contract=1, Change=2, Variable=3, ContractCreated=4).
  2. Use the SDK's transaction request builders (e.g. `ScriptTransactionRequest.addOutput()`) which set the type automatically, rather than raw object literals.
  3. Align @fuel-ts package versions so enum values match across serialization and deserialization.
  4. If you see this error, also note the error code is mislabeled as INPUT but the fault is with an output.

Example fix

// before
request.outputs.push({ to: alice.address, amount: 1000, assetId: '0x...' });
// after
import { OutputType } from '@fuel-ts/transactions';
request.outputs.push({
  type: OutputType.Coin,
  to: alice.address,
  amount: 1000,
  assetId: '0x...',
});
Defensive patterns

Strategy: type-guard

Validate before calling

import { OutputType } from '@fuel-ts/transactions';
const KNOWN = new Set([OutputType.Coin, OutputType.Contract, OutputType.Change, OutputType.Variable, OutputType.ContractCreated]);
if (!KNOWN.has(output.type)) throw new Error(`bad output type ${output.type}`);

Type guard

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

Try / catch

try { request.addOutput(outputify(rawOutput)); } catch (e) { if (e.code === ErrorCode.INVALID_TRANSACTION_INPUT && /output/i.test(e.message)) { /* skip */ } else throw e; }

Prevention

When it happens

Trigger: Calling `outputify()` or `TransactionRequest.from()` with an output object whose `type` is undefined or outside the OutputType enum. Reaching output.ts:98 default branch during serialization of a transaction request to a chain-ready transaction.

Common situations: Hand-constructing output objects without setting `type`; version skew where OutputType enum values changed; serializing a transaction built by an older SDK that lacks newer output types; passing an output shaped like a `Coin` but missing the discriminator field.

Related errors


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