This repository was archived by the owner on Feb 26, 2024. It is now read-only.
Enhancement: Include raw event data in txlog #5324
Merged
Conversation
This file contains 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
haltman-at
requested review from
gnidan,
benjamincburns and
cds-amal
and removed request for
benjamincburns
haltman-at
changed the title
|
@haltman-at I concur... we should remove the redundancy and replace it with an easy-to-use selector |
|
Cool. Should the |
You know how I feel that everything that can be separate, should be separate ;) |
|
Cool, that's what I had intended anyway. :) |
gnidan
approved these changes
Jul 20, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This one is pretty straightforward. It adds a
rawfield toeventactions in the txlog, so there will be info even if decoding failed. Therawfield has four subfields:address,codeAddress,topics, anddata. Thetopicsanddatafields are what you expect. Theaddressis the address that officially omitted the event, andcodeAddressis the address of the code that emitted the event. These can be different if the event was emitted from a delegatecall (e.g. a library), as officially it's the caller of the library that emits the event, but I thought it was good to include thecodeAddressas well to tell you what contract's code emitted the event.Note that if an event is emitted from a constructor, both
addressandcodeAddresswill be equal to the address that the contract was being created at (barring some cases where we can't determine it, in which case they'll show as zero instead, sorry -- although this will only ever happen for reverted events).I also expanded the existing tests to test this new functionality.
(Actually, wait, thought, now that I've done this -- should
addressandcodeAddressbe dropped? They're derivable from the rest of the txlog, which seems to go against how txlog works in general; it generally doesn't include derivable info like that. Like if you think about the original purpose oftxlogas a visualization tool, this address info wouldn't be used, because it would already be implicit from the diagram. Should I remove those?)