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
- Pass exactly one of commitBlockId or commitBlockHeight (or omit both to let the node resolve).
- If you have a height, prefer commitBlockHeight; if you have a block id, prefer commitBlockId.
- Add a guard before the call: if (commitBlockId && commitBlockHeight) throw locally with a clearer message.
- 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
- Pass at most one of commitBlockId / commitBlockHeight.
- Centralize message-proof calls in one helper enforcing the invariant.
- Prefer the value you actually have rather than both.
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.