feat: add logs to transaction receipts#153
Open
FarajiOranj wants to merge 1 commit into
Open
Conversation
`waitForTransaction` returned a `TransactionReceipt` that exposed `logsBloom` but not the actual `logs`, so events emitted by a transaction (e.g. reading a newly deployed contract address from a factory event) couldn't be accessed without dropping down to a raw client. Add a raw `Log` type and a `logs` field on `TransactionReceipt`, and populate it in every adapter: default (ox), viem, ethers v6, ethers v5, and web3. `EventLog` now extends `Log`, and `createStubTransactionReceipt` defaults `logs` to an empty array.
🦋 Changeset detectedLatest commit: b37d6a0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #151.
waitForTransactionreturned aTransactionReceiptthat exposedlogsBloombut not the actual
logsarray, so you couldn't read a transaction's emittedevents (e.g. grabbing a newly deployed contract address from a factory event)
without dropping down to a raw client. This wires the logs through on every
adapter.
Changes
Logtype inadapter/types/Event.ts: a raw, undecoded log entry(address, data, topics, block/transaction position,
removed).EventLogisnow
Log & { eventName, args }so the decoded and raw shapes stay in sync,and
Logis exported from the package root.TransactionReceipt.logs: Log[]added (replacing the existing// TODO: logs: Log[]).logsinwaitForTransaction:@gud/driftDefaultAdapter(oxTransactionReceipt.fromRpc)@gud/drift-viem@gud/drift-ethers(ethers v6; mapslog.index->logIndex)@gud/drift-ethers-v5@gud/drift-web3(defensive number/undefinedhandling for web3'sformatted receipt)
createStubTransactionReceiptnow defaultslogs: [], and everyadapter's receipt assertion checks the new field.
minor).Notes / possible follow-ups
WalletCallsReceiptcarries the same// TODO: logs: Log[]for EIP-5792receipts. I kept this PR focused on
waitForTransaction; happy to follow upon the wallet-calls receipt in a separate PR if useful.
out of an adapter. That's a separate feature from this one, so I left it out
of this PR to keep it focused, but glad to take it on if you'd like.