decoding indexed events is incorrect

[martyall]

In order to parse an indexed event, it is not enough to simply have the data field of the Change object, you also will need the topics field. See the definition of the decoding schema. This is a pretty serious problem in that ERC20 contracts have indexed events, so this means that you will not be able to parse them correctly.

This makes parsing somewhat difficult because it requires you to recombine two tuples in an arbitrary way in order to reconstruct the event type. purescript-web3 solves this problem in a way which is somewhat dependent on row types. I'm not sure what the best solution is here.

This problem is somewhat related to the other outstanding encoding/parsing bugs. I think you should consider replacing some of your template haskell with generics as it's easer to maintain and reason about. I can volunteer to put together a pr based on what we learned in purescript-web3 generic parsing/encoding. Would you all be open to something like this?

[akru]

Thank you for reporting!

Genetics in parser/encoder looks good, what changes is needed to adapt your ps code to Haskell?

@aupiff what do you think about this proposal? Do you currently works on encoding bug fixes?

[martyall]

well basically I would mimic the ps set up. This would not change the encoding of any "basic" (i.e. non-tuple) solidity type. Then Tuples will be done generically, and finally the call and sendTx functions will only require the generic encoding decoding -- see this to get an idea of what that looks like.

For the proper parsing of events, it's a bit harder to explain what I'll do in advance, but it will most likely involve some simple type level programming.

the output of this is that you will effectively only need the TH file to generate the helper functions, e.g. things like transfer :: Address -> UInt -> Web3 TxHash in an ERC20 contract, and the event types, e.g. data Transfer = Transfer Address Address UInt.