inconsistent args type

[coinlordd]

Is there an existing issue for this?

• I have searched the existing issues

Package Version

0.3.41

Current Behavior

Consider the following code snippet:

client.watchContractEvent({
    address: '0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f', // UniswapV2Factory
    abi: UNISWAP_V2_FACTORY,
    eventName: 'PairCreated',
    onLogs: (logs) => {
      logs.forEach((log) => {
        console.log(log.args)
      })
    },
  })

where the PairCreated event in UNISWAP_V2_FACTORY has the following inputs:

inputs: [
   { indexed: true, internalType: 'address', name: 'token0', type: 'address' },
   { indexed: true, internalType: 'address', name: 'token1', type: 'address' },
   { indexed: false, internalType: 'address', name: 'pair', type: 'address' },
   { indexed: false, internalType: 'uint256', name: '', type: 'uint256' }
]

log.args will yield a tuple of results for both the actual response and the inferred types, typed as follows:

readonly [`0x${string}`, `0x${string}`, `0x${string}`, bigint] | readonly [`0x${string}`, `0x${string}`, `0x${string}`] | readonly [`0x${string}`, `0x${string}`] | readonly [`0x${string}`]

This is slightly indesirable as opposed to returning a key/value pairing. However, if we were to remove the last argument of the inputs array - as shown below - args will no longer yield a tuple, but instead the desired object.

inputs: [
   { indexed: true, internalType: 'address', name: 'token0', type: 'address' },
   { indexed: true, internalType: 'address', name: 'token1', type: 'address' },
   { indexed: false, internalType: 'address', name: 'pair', type: 'address' }
]

The output will be of type:

{
    token0?: `0x${string}` | undefined;
    token1?: `0x${string}` | undefined;
    pair?: `0x${string}` | undefined;
}

It appears the issue emerges due to name-less input arguments. It being the last argument in the inputs array is merely coincidence. Moving it to a different position produces the same issue.

Expected Behavior

The output isn't consistent, nor is it desirable for many. I'd expect it to return a key/value pairing at all times.

Steps To Reproduce

The example I've shared above uses the watchContractEvent function. However it happens to all other functions that make use of the Log[] return type.

Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

https://viem.sh/docs/actions/public/getLogs.html#returns

Anything else?

No response

[coinlordd]

I realize now that a name-less argument cannot be used in a key/value mapping because it has no keys. However, perhaps it's an idea to construct the object regardless using the known keys, and add a special property that lists the unknown values.

One could suggest to just remove the name-less argument from the inputs array alltogether to get the desired result, however I'm not sure if that were to alter the function selector and thus no events would be picked up. Any ideas how we could bypass this?

[jxom]

Could perhaps make the unnamed argument's key a number of the position it is in, ie:

{
  token0: Address,
  token1: Address,
  pair: Address,
  3: uint256
}

Think this would work as numbers aren't a valid solidity argument. What do you think?

[jxom]

Going to move this to discussions as this is more of a feature request than a bug, but definitely want to address this soon!

[coinlordd]

After some thought I think the best course of action would be to:

1. Encourage devs to alter the nameless keys into a string with len > 0. As long as the type is known (which it is) the function selector remains the same.
2. Ignore nameless keys alltogether in order to consistently return an object. This also ties in with (1), where devs who really need to map that key are encouraged to alter it.

What do you think?