FuelLabs/fuels-ts · warning · FuelError

INVALID_INPUT_PARAMETERS

INVALID_INPUT_PARAMETERS

Error message

commitBlockId and commitBlockHeight cannot be used together

What it means

Thrown by Provider.getMessageProof when both commitBlockId and commitBlockHeight are supplied simultaneously. The node's message-proof query accepts at most one commit-block reference; passing both is ambiguous, so the SDK rejects it before sending the request. Provide one or the other (or neither).

Source

Thrown at packages/account/src/providers/provider.ts:2386

    transactionId: string,
    nonce: string,
    commitBlockId?: string,
    commitBlockHeight?: BN
  ): Promise<MessageProof> {
    let inputObject: {
      /** The transaction to get message from */
      transactionId: string;
      /** The message id from MessageOut receipt */
      nonce: string;
      commitBlockId?: string;
      commitBlockHeight?: string;
    } = {
      transactionId,
      nonce,
    };

    if (commitBlockId && commitBlockHeight) {
      throw new FuelError(
        ErrorCode.INVALID_INPUT_PARAMETERS,
        'commitBlockId and commitBlockHeight cannot be used together'
      );
    }

    if (commitBlockId) {
      inputObject = {
        ...inputObject,
        commitBlockId,
      };
    }

    if (commitBlockHeight) {
      inputObject = {
        ...inputObject,
        // Convert BN into a number string required on the query
        // This should probably be fixed on the fuel client side
        commitBlockHeight: commitBlockHeight.toNumber().toString(),

View on GitHub (pinned to b3f37c91ac)

Solutions

  1. Pass exactly one of commitBlockId or commitBlockHeight (or omit both to let the node resolve).
  2. If you have a height, prefer commitBlockHeight; if you have a block id, prefer commitBlockId.
  3. Add a guard before the call: if (commitBlockId && commitBlockHeight) throw locally with a clearer message.
  4. Audit call sites that forward both args and pick one based on which is more authoritative.

Example fix

// before
await provider.getMessageProof(txId, nonce, blockId, blockHeight);

// after — pass only one reference
await provider.getMessageProof(txId, nonce, blockId /*, undefined */);
// or
await provider.getMessageProof(txId, nonce, undefined, blockHeight);
Defensive patterns

Strategy: validation

Validate before calling

function assertSingleBlockRef(commitBlockId?: string, commitBlockHeight?: unknown) {
  if (commitBlockId && commitBlockHeight) {
    throw new Error('Pass either commitBlockId or commitBlockHeight, not both.');
  }
}

Type guard

function hasMutuallyExclusiveBlockRef(commitBlockId?: string, commitBlockHeight?: unknown): boolean {
  return !(commitBlockId && commitBlockHeight);
}

Try / catch

import { FuelError, ErrorCode } from '@fuel-ts/errors';
try {
  await provider.getMessageProof(txId, nonce, commitBlockId, commitBlockHeight);
} catch (e) {
  if (e instanceof FuelError && e.code === ErrorCode.INVALID_INPUT_PARAMETERS) {
    // drop one of the two block references and retry
  }
  throw e;
}

Prevention

When it happens

Trigger: Calling provider.getMessageProof(txId, nonce, commitBlockId, commitBlockHeight) with both optional block-reference arguments populated; copying a call signature and filling every optional field.

Common situations: Caller has both values handy and passes both for 'completeness'; refactor merged two code paths that each set one field; misunderstanding the overloads as additive rather than exclusive.

Related errors


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