Reasoning of optional fields in TransactionReceipt

[pstuermlinger]

Hi,
the TransactionReceipt interface is currently defined as

export interface TransactionReceipt {
    to?: string;
    from?: string;
    contractAddress?: string;
    transactionIndex?: number;
    root?: string;
    gasUsed?: BigNumber;
    logsBloom?: string;
    blockHash?: string;
    transactionHash?: string;
    logs?: Array<Log>;
    blockNumber?: number;
    confirmations?: number;
    cumulativeGasUsed?: BigNumber;
    byzantium: boolean;
    status?: number;
}

AFAIK, we can only receive a receipt when the transaction in question has been mined. With this axiom, I'd expect to always have a value on most of the receipts fields (all?).
Are there any edge cases where some of those fields are missing in a receipt? Has this to do with different node implementations? Or will a node produce an incomplete receipt if a previously mined transaction has been removed due to a chain reorganization?

I'd be glad if anyone could shed some light on this.

Thank you!
Patrick

[ricmoo]

Yes, this has been an issue in the case of Ganache, which is generally not very standards compliant, and depending on the version would return and fail to return certain fields.

I do not recall the specifics of this (as the fields were made option quite some time ago), but it was for a reason. Something was failing if we forced those things to be present. It may have been orphaned transactions.

I'll scratch my head a bit and try to remember more of the details. :)

[pstuermlinger]

Ah, that's good to know. If this ist just about a development blockchain I might consider to Required<TransactionReceipt> your interface with all fields present. That would avoid a lot of non-null-assertions in my code (which makes me feel like a bad guy 😄 )

[ricmoo]

I've made this change in v5, if you'd like to check it out:

https://github.com/ethers-io/ethers.js/blob/ethers-v5-beta/packages/abstract-provider/src.ts/index.ts#L96

The root vs status are both still optional, since those depend on whether the transaction is in a post-byzantium block.

[ricmoo]

I think this is now taken care of (in v5)? I'm going to close this now, but please feel free to re-open if there are any issues.

Thanks! :)

[zjiekai]

ethers.js/packages/providers/src.ts/formatter.ts

Lines 111 to 129 in 608864f

	formats.receipt = {
	to: Formatter.allowNull(this.address, null),
	from: Formatter.allowNull(this.address, null),
	contractAddress: Formatter.allowNull(address, null),
	transactionIndex: number,
	// should be allowNull(hash), but broken-EIP-658 support is handled in receipt
	root: Formatter.allowNull(hex),
	gasUsed: bigNumber,
	logsBloom: Formatter.allowNull(data),// @TODO: should this be data?
	blockHash: hash,
	transactionHash: hash,
	logs: Formatter.arrayOf(this.receiptLog.bind(this)),
	blockNumber: number,
	confirmations: Formatter.allowNull(number, null),
	cumulativeGasUsed: bigNumber,
	effectiveGasPrice: Formatter.allowNull(bigNumber),
	status: Formatter.allowNull(number),
	type: type
	};

Is the allowNulls related to this issue?

ethers.js/packages/providers/src.ts/formatter.ts

Lines 418 to 420 in 608864f

	if (result.status != null) {
	result.byzantium = true;
	}

btw why the byzantium field?