How to decode an event without knowing indexed parameters?

[mds1]

Whether or not event parameters are indexed is not part of the topic hash, which is giving me some issues when I try to decode events based just on the topic. Here's my specific example, where the event topics and data are returned from a Tenderly simulation, so I have to figure out the event signature from 4byte.directory

// Returned from an API:
const topics = [
  '0xd8c9334b1a9c2f9da342a0a2b32629c1a229b6445dad78947f674b44444a7550',
  '0xa35d592ec6e5289a387cba1d5f82be794f495bd5a361a1fb314687c6aefea1f4',
  '0x2516c29f14a1d89a415d7a3c3e8c3201e2ea4e2d9531ef0821f8c347525af95c'
]
const data = '0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000021566f6c747a20556e69207633204164646974696f6e616c20557365204772616e7400000000000000000000000000000000000000000000000000000000000000'

// Sanity checking data length (this returns true)
data.slice(2).length % 32 

// Full event interface, from the ENS Public Resolver
const ifaceGood = new Interface(['event TextChanged(bytes32 indexed node, string indexed indexedKey, string key)'])

// Partial event interface, found by querying 4byte.directory for the first topic in the above array.
const ifaceBad = new Interface(['event TextChanged(bytes32,string,string)'])

// This works
ifaceGood.parseLog({data, topics}) // returns the parsed log

// These both error with:
//   reason: 'data out-of-bounds',
//   code: 'BUFFER_OVERRUN',
//   length: 95,
//   offset: 8576
ifaceBad.parseLog({ data, topics })
ifaceBad.parseLog({ data, topics: [topics[0]] })

For this specific use case, I know what the event signature should be and can hardcode a workaround, but of course that doesn't scale very nicely so I'm wondering if there's a way to decode the event parameters without knowing which ones are indexed?

[zemse]

I don't think there is a straightforward way to do this. From the topics array, we can know the number of indexed parameters. E.g. in your case, it's two. So possible permutations would be three. The fact that types like address or uintx have upper bounds as well as the topics are in order of parameters, multiple permutations can be ruled out to make the complexity of the algorithm better. But yeah param types like (bytes32,string,string) will yield the worst-case complexity with this kind of algorithm.

[ricmoo]

Exactly correct. There is no way to know. :(

Don’t worry, it is pretty high on my list of “things I’d have changed if I ever get sent back in time” though.

[mds1]

Thanks to you both!

@ricmoo I'd love to read an article with everything on that list, plus it will help me know what to do once my time machine is working

[ricmoo]

I'm thinking of publishing it. ;)