Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with types of getTransactionReceipt() and generic ReturnFormat #6372

Closed
cristianorvf opened this issue Aug 20, 2023 · 4 comments
Closed
Assignees
Labels
4.x 4.0 related Bug Addressing a bug

Comments

@cristianorvf
Copy link

cristianorvf commented Aug 20, 2023

Expected behavior

When the Number and Bytes type is passed to the typesystem it should return back the correct format desired.

Actual behavior

The object is getting the correct format, but hte typesystem is not.

Steps to reproduce the behavior

  1. Start a new project npm init -y && npm i [email protected]
  2. Create the a simple code to getTransactionReceipt()
import Web3, { FMT_BYTES, FMT_NUMBER } from "web3";

async function main() {
    const web3 = new Web3('<SOME_ENDPOINT>')

    const receipt = await web3.eth.getTransactionReceipt('<SOME_HASH>',
        { number: FMT_NUMBER.NUMBER, bytes: FMT_BYTES.HEX })

    const hex: string = receipt.blockHash
}

main()

Logs

web3test.ts:10:11 - error TS2322: Type 'Bytes' is not assignable to type 'string'.
Type 'Uint8Array' is not assignable to type 'string'.

10 const hex: string = receipt.blockHash

Environment

OS: OS X VENTURA 13.4
NODE: v18.13.0
NPM: 9.6.6
TS: Version 4.9.5

@jdevcs jdevcs added the 4.x 4.0 related label Aug 21, 2023
@jdevcs
Copy link
Contributor

jdevcs commented Aug 21, 2023

Thanks for details in description section.

blockhash is Bytes , that can be Uint8Array or string based on input formatters, as here you are fully sure you want FMT_BYTES.HEX string so for now you may:

    const result: Bytes = receipt.blockHash;
    const blockHash: string = result as string;

or

const result: string = receipt.blockHash as string;

@cristianorvf
Copy link
Author

Thanks for details in description section.

blockhash is Bytes , that can be Uint8Array or string based on input formatters, as here you are fully sure you want FMT_BYTES.HEX string so for now you may:

    const result: Bytes = receipt.blockHash;
    const blockHash: string = result as string;

or

const result: string = receipt.blockHash as string;

Hi @jdevcs, yes i can "cast as", but the questions is why have such specification in the signatures if the returned type might be the union of both.. ? Furthermore, in my case there is an interface in place expecting it as string, i might do the union there only to propagate the typecheck across all other resources that use such class.

The point is, is this the expected behavior? If so, why bother at all passing the specific type desired? Im i missing something?

@andhovesyan
Copy link

Same for getTransaction in web3_eth.d.ts returnFormat is ignored:

getTransaction<ReturnFormat extends DataFormat = typeof DEFAULT_RETURN_FORMAT>(transactionHash: Bytes, returnFormat?: ReturnFormat): Promise<{
        readonly yParity: string;
        readonly r: string;
        readonly s: string;
        readonly maxFeePerGas: string;
        readonly maxPriorityFeePerGas: string;
        readonly accessList: {
            readonly address?: string | undefined;
            readonly storageKeys?: string[] | undefined;
        }[];
        readonly to?: string | null | undefined;
        readonly type: string;
        readonly nonce: string;
        readonly gas: string;
        readonly value: string;
        readonly input: string;
        readonly data?: string | undefined;
        readonly chainId?: string | undefined;
        readonly hash: string;
        readonly blockHash?: string | undefined;
        readonly blockNumber?: string | undefined;
        readonly from: string;
        readonly transactionIndex?: string | undefined;
    } | {
        readonly yParity: string;
        readonly r: string;
        readonly s: string;
        readonly gasPrice: string;
        readonly accessList: {
            readonly address?: string | undefined;
            readonly storageKeys?: string[] | undefined;
        }[];
        readonly to?: string | null | undefined;
        readonly type: string;
        readonly nonce: string;
        readonly gas: string;
        readonly value: string;
        readonly input: string;
        readonly data?: string | undefined;
        readonly chainId?: string | undefined;
        readonly hash: string;
        readonly blockHash?: string | undefined;
        readonly blockNumber?: string | undefined;
        readonly from: string;
        readonly transactionIndex?: string | undefined;
    } | {
        readonly v: string;
        readonly r: string;
        readonly s: string;
        readonly gasPrice: string;
        readonly to?: string | null | undefined;
        readonly type: string;
        readonly nonce: string;
        readonly gas: string;
        readonly value: string;
        readonly input: string;
        readonly data?: string | undefined;
        readonly chainId?: string | undefined;
        readonly hash: string;
        readonly blockHash?: string | undefined;
        readonly blockNumber?: string | undefined;
        readonly from: string;
        readonly transactionIndex?: string | undefined;
    }>;

@mconnelly8 mconnelly8 added the Bug Addressing a bug label Apr 16, 2024
@luu-alex
Copy link
Contributor

@cristianorvf this is incorrect and will be fixed. sorry for the long wait. Will create a PR

@luu-alex luu-alex self-assigned this Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4.x 4.0 related Bug Addressing a bug
Projects
None yet
Development

No branches or pull requests

5 participants