-
Notifications
You must be signed in to change notification settings - Fork 1
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
add timestamp to ethr builder #48
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #48 +/- ##
==========================================
- Coverage 97.27% 97.25% -0.02%
==========================================
Files 13 13
Lines 2826 2953 +127
==========================================
+ Hits 2749 2872 +123
- Misses 77 81 +4 ☔ View full report in Codecov by Sentry. |
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!
Looks like we need a rustfmt.toml to unify cargo fmt
we should be just on the stable default rustfmt settings, in this case my lsp crashed and i didn't get the autoformatting I usually do |
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 think we should be consistent in our use of block timestamp in seconds
removed logic to convert to datetime b/c it was wasteful, changed to store the usual timestamp and then multiply for nanoseconds @jac18281828 |
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.
Looks good ! One last thing, I’d use Duration for time conversion.
related to xmtp/xps-gateway#61
timestamp is not the best way b/c we can have multiple installation id updates in the same block. It may be OK in the general case, since it could be rare that a user updates their installation key in the same block twice, but it can happen. libxmtp relies on it in order to sort through installation ids it already has. In the future it would be better to use a block # / log index combo. This would also avoid yet another api call to the ethereum rpc node