Skip to content
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

Fix issue handling bucketTake events #30

Merged
merged 3 commits into from
Jul 13, 2023
Merged

Fix issue handling bucketTake events #30

merged 3 commits into from
Jul 13, 2023

Conversation

EdNoepel
Copy link
Contributor

@EdNoepel EdNoepel commented Jul 13, 2023

There was a chicken-and-egg problem handling bucketTake. BucketTakeLPAwardedEvent is currently emitted before BucketTakeEvent. As such, when the LP award looked up the BucketTake entity, it was unexpectedly null.

Because BucketTakeLPAwardedEvent does not have enough information to build the BucketTake, we now create a placeholder which references the LP award event. When the BucketTakeEvent occurs (on the very next log index), it looks up the LP award event and updates state of all related entities. We associate these events by assuming the take event will always be the subsequent log index, which a cursory review of the code reveals is the case. Reviewer should confirm.

This should handle the case where multiple bucketTakes occur in a single transaction, but that remains untested.

Tested on parvati, which is able to sync up to current block height on goerli (9336296).

@EdNoepel EdNoepel changed the title Fix for issue handling bucketTake events Fix issue handling bucketTake events Jul 13, 2023
@@ -313,9 +313,8 @@ export function handleBucketBankruptcy(event: BucketBankruptcyEvent): void {
}

export function handleBucketTake(event: BucketTakeEvent): void {
const bucketTake = new BucketTake(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to assume the next log index at all? Shouldn't the transaction hash and block number concat still work for the ID?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how block number helps us. A transaction hash may contain multiple bucketTake actions. As such, we need the log index. The LP award should always be followed by the bucket take event.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, I had the issue backwards - this makes sense

}
return bucketTake;
}1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: trailing 1 and no extra line

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 25b6954

Copy link
Contributor

@MikeHathaway MikeHathaway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@EdNoepel
Copy link
Contributor Author

Example query screenshot:
image

@EdNoepel EdNoepel merged commit 245bf7c into develop Jul 13, 2023
@EdNoepel EdNoepel deleted the 1220 branch July 13, 2023 03:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants