feat(subgraph): Receipts improved #13824
Conversation
subgraph/src/receipt.ts
Outdated
| const txLog = logs[i] | ||
|
|
||
| if ( | ||
| // txLog.address == UNLOCK_ADDRESS && |
There was a problem hiding this comment.
I am not sure how to do that since we don't actually have Unlock's address here?
| // We cannot trust `event.transaction.value` because the purchase function could in fact | ||
| // be happening inside of a larger transaction whose value is not the amount transfered, | ||
| // In that case, we need to look up the GNPChanged event | ||
| if (logs) { |
There was a problem hiding this comment.
It seems that part is only needed if the tx value is null
There was a problem hiding this comment.
That's what I initially thought, but in fact the transaction.value could also be "wrong". Imagine if a safe tx buys 2 keys but starts with a 3rd tx in the buddle which funds the safe? Thent the value would be wrong
There was a problem hiding this comment.
Yes in the case of a safe or a multicall then the value can be calculated with the GNP.
Also for multiple purchases the tx.value is the total of all keys purchased, so using that will be wrong too
There was a problem hiding this comment.
Actually, that is a very good point. For receipts we actually have a single receipt per transaction, even if it ends up minting multiple keys (similar to when you buy multiple things at once you only get a single receipt at the store).
So my approach of looking at the GNP is not great.
I guess I can loop over all the GNP changed events for now.
We really need an event to be triggered for receipt, like PurchaseReceipt() that would include the required details: payer, contract, totalPaid, hash... etc.
| tokenAddress: Address, | ||
| refund: BigInt | ||
| ): ethereum.TransactionReceipt { | ||
| return newTransactionReceipt([ |
There was a problem hiding this comment.
Ohhh! That makes sense. I am not sure why I assumed there could be a single "log" per mocked transaction.
nvm. When an event is fired from another contract, the topics are passed as data... |
* adding comments * using the GNP_CHANGED event to identify values in subgraphs * undue change * extracting the unlock address * fixed wasm * fixing API * fixing mocks * adding more comments * add test case for GNPChanged * better mock * unit test ok * use data field in receipt instead of topics * Update subgraph/src/receipt.ts * Update subgraph/tests/mockTxReceipt.ts --------- Co-authored-by: Clément Renaud <clement@unlock-protocol.com> Co-authored-by: Clément Renaud <clement+git@clementrenaud.com>
Description
We recently found that accessing the transaction's
valuewas not accurate because the call topruchaseKeyscould be happening in a "larger" transaction with a different value.In order to handle this, in the short term, we are looking at the GNPChange event's value.
Checklist:
Release Note Draft Snippet