-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: events for ibc transfers #4874
Conversation
17ce98c
to
189bf3c
Compare
This adds events for outbound, inbound, and refunds. This also adds sufficient metadata to uniquely identify which transfer is being refunded, and where transfers are going.
189bf3c
to
73ed720
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Note: there is a bug in this and the related PR for refunds, where the receiver address for refunds is populated incorrectly. |
73ed720
to
d682205
Compare
Fixed on latest push, confirm? |
Confirmed with @cronokirby out of band that this patch is good to go. |
Refs #4871 |
## Describe your changes This implements indexing for IBC transfer events. Merge #4874 first. ## Checklist before requesting a review - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > indexing only
A backport of #4874 to v0.79.X, for reindexing purposes.
Describe your changes
This adds specific events related to fungible token transfers, recording them as they happen in the shielded pool.
First of all, this is a much more legible and readily consumable event around actual IBC events we care about, which is reason enough to have this, imo, but also, there's currently a flaw in the whole event system in that we don't have access, through events only, to the actual acknowledgement data for a packet.
In particular, we can't tell using the raw ibc events if a packet was acked successfully, finalizing a transfer, or unsuccessfully, causing the transfer to be refunded.
Knowing which of the two matters a lot, and will cause queries like "how much of this asset has been locked in the shielded pool" to not return the right result by quite a bit.
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: