-
Notifications
You must be signed in to change notification settings - Fork 43
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
Improve log poller codec usage and optimise log event discriminator matching #1014
Conversation
a3ad8c0
to
577d1be
Compare
0c844c5
to
e0d05b3
Compare
e0d05b3
to
3e58e35
Compare
Faster than what? It can't be faster than the existing implementation which just does a simple lookup in |
pkg/solana/logpoller/log_poller.go
Outdated
// TODO isn't discrimintaor already checked above in MatchingFiltersForEncodedEvent? | ||
if len(log.Data) < 8 { |
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.
I added this check to address a PR comment from @dhaidashenko requesting more validation, in case it's not 8 bytes. I added it, but noted that it isn't something that can happen with the existing code--would just protect against someone accidentally introducing a bug later.
I don't care much either way whether we leave it or take it out, but if you want to take it out you should get @dhaidashenko approval.
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.
(If not, remove TODO comment)
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.
DecodeSubKey uses codec decode which also checks for discriminator, so I don't think that there is any need for this extra validation step
The description of the PR as optimizing the event matching is misleading, since it's not optimizing anything relative to the current implementation. But it's a more self-contained way of handling the discriminators we might be able to re-use at some point, and adds negligible overhead so I am happy with it. Just pointed out a few minor cosmetic issues to fix. |
if err != nil { | ||
if err = decoder.Decode(ctx, raw, decodedEvent, filter.EventName); err != nil { | ||
err = fmt.Errorf("failed to decode sub key raw data: %v, for filter: %s, for subKeyPath: %v, err: %w", raw, subKeyPath, filter.Name, err) | ||
lggr.Criticalw(err.Error()) |
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.
critical because it shouldn't ever happen, it would mean that log discriminators match, but what the onchain contract emitted is malformed
3cef275
to
53174c0
Compare
Quality Gate passedIssues Measures |
Description