Is it possible to enable Parity RPC method trace_rawTransaction?

I want to use the Parity RPC method trace_rawTransaction in order to get a revert message from a failed transaction on Kovan, however it looks like the trace methods are not available on Infura nodes. Can this be enabled?

Hi Shane. Tracing support is something on our roadmap but it isn’t available yet. I know a lot of people want access to tracing specifically for the revert with reason data. I don’t think there is a workaround at this time short of running your own kovan tracing node.

1 Like

Great. Thank you for the response. One follow-up question, are all nodes on Infura Geth nodes, with the exception of Kovan?

For the most part. We don’t run only geth nodes but our API is meant to be conformant with the geth API spec as the default behavior. In the future we will likely add support for non geth API methods that developers request such as the tracing api or other parity specific methods.

1 Like

Great. And finally, we can expect consistent return data from calls, whether they are running Geth or Parity, correct? I cannot think of an example on the top of my head, but in the event that an RPC call to Geth would return Error: x and Parity would return { error: { code: 1234, message: 'x' } }, would an Infura user always receive the same return data from Infura, regardless of the underlying node?

There are differences which is why we stuck to supporting one implementation version.

I don’t have a list of the differences but some examples are things like parity including fields which geth does not such as an author field on blocks and not geth not including transactionLogIndex in getLogs responses.

Would an Infura user always receive the same return data from Infura, regardless of the underlying node?

For the API we aim to conform to the underlying spec which is what guides geth development. Unfortunately, this spec isn’t as rigid as you would expect and so client implementations have drifted on things like error messages. We try to raise these issues with the dev teams and try to get them to fix them upstream if possible. In a few cases we have had to make changes on our side to keep errors consistent. There may be future occurrences though which will catch users off-guard. One of the reasons we recommend ethers.js to users over web3 is because the maintainer does his best to abstract those differences on the library side and does a really good job at it. If you aren’t using it already, I would recommend switching.

1 Like

Awesome! Thank you for the responses.

@egalano One follow-up question related to this: is there a convenient way with Infura to know if the trace methods are exposed without making a call and looking for the “Please expose the trace methods” error? Maybe an endpoint, /v1/getTraceEnabled, or something?

Similar question with regards to an archive node.

Sorry Shane I missed your response. If you are talking directly to a local node there isn’t a way to know which methods are exposed without trying them. We list our available methods on our docs page but it isn’t accessible programatically. It is something we could add as a feature though.

Ok great. I actually started another thread here because it seemed more relevant. Would love to discuss further and hear the opinions of the Infura team.