transaction.gasUsed is not gasUsed.

[Amxx]

When handling an event, I wanted to log gas-related information.
However, I noticed that event.trasaction.gasUsed does not contain the gas used but gas limit.

It would be nice to gas these 2 entries (gasUsed and gasLimit) in the transaction object

[smsunarto]

Happened to me too. I know this might be a niche use case but would really love to have a fix for this.

I'm desperate: https://twitter.com/smsunarto/status/1318195502127542273

[leoyvens]

@smsunarto Sorry that you lost time with this! First this needs to be renamed to gasLimit. Then we need to figure out the best way to expose gasUsed, which comes in the transaction receipt which is more expensive to fetch so we don't want to fetch it by default.

[krishan711]

I'd be keen to help with this if I can but I don't know where to start. Any pointers would be greatly appreciated.

[sc0Vu]

It happened to me, I thought the gasUsed is the gas cost for transaction.

IMHO, before add transaction receipt's gasUsed, it would be better rename the gasUsed to gas?

[benesjan]

Hello, is there any plan to fix this? It is causing issues in Uniswap v3 subgraph. Thank you

[drortirosh]

any chance of adding real gasUsed ?
Probably has to be added as a method call - since indeed not all handlers need actual gas, and it takes an extra call to the node, much like view calls into the contracts.

[azf20]

Thanks all - @leoyvens was looking into options here, as you say @drortirosh this requires an extra eth call to the node so there are performance considerations

[crazyrabbitLTC]

Hey folks, we've been tracking gasUsed in all our subgraphs, assuming it was a real number. We've only just now discovered that actually, it's not a real number now that we're in the middle of exposing to users the real costs of transactions, meaning we have to go back to the drawing board for both new product features and a research report.

I understand that maybe it's a performance consideration for not fetching the real gasUsed but was it ever considered to return null or 0 so that the developer knew this wasn't a real feature and so that we don't build our products on top of it thinking it's real? (since 2019?!)

Using TheGraph as a source of truth instead of the blockchain requires that we trust the data from TheGraph. Feels pretty important that if the data returned is known to not be correct, or be something different, that this gets flagged for the developer in the code.

[azf20]

Hey @crazyrabbitLTC very sorry about that. In the immediate term @leoyvens has made a change to rename gasUsed to gasLimit graphprotocol/graph-ts#192 (will be in a new graph-ts version). We have also been making changes to fetch tx receipts, which could extend to surface the actual gasUsed, will keep this issue open to track.
Definitely heard on the developer communication point, and apologies for any time lost

[NelsonGaldeman]

Hi @leoyvens & @azf20 ! Is there any ETA for gasUsed support? We've been relying on gasUsed at SimpleFi. We started upgrading our subgraphs to 24.1 and found it's always been gasLimit. Thank you.

[twotimeseleven]

Bumping this issue. Would be fantastic to track gasUsed for transactions, even if the team could provide a workaround calculation method (though I am not aware of one).

[mariorz]

Bumped and agree with the sentiment here, gasUsed is confusingly named and getting actual gasSpent should be considered an absolute requirement. Thanks!

[leoyvens]

Including the receipt is being worked on and tracked here #3218

[azf20]

Hi this is available on the Hosted Service with the alpha versions of graph-ts and graph-cli, and will be in the next Graph Node release, documentation here graphprotocol/docs#102. Note that an eventHandler has to specifically require receipts. Kudos to @tilacog and @evaporei

[nhd98z]

Can you also add the l1GasUsed, l1GasPrice, l1FeeScalar of to event.transaction? (For optimism transactions).