-
Notifications
You must be signed in to change notification settings - Fork 113
Conversation
332903d
to
7653fdb
Compare
@@ -1,4 +1,4 @@ | |||
package ethereum | |||
package signer |
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 had to move this into it's own sub-package in order to break a circular import 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.
@fabio I still need to take a closer look at some parts of this PR (including the tests), but in the interest of time I am submitting my thoughts so far.
// many from the bucket so that it starts empty for the next 24hr period | ||
r.mu.Lock() | ||
accruedGrants := r.maxRequestsPer24Hrs - r.grantedInLast24hrsUTC | ||
if err := r.twentyFourHourLimiter.WaitN(ctx, accruedGrants); err != nil { |
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.
Shouldn't we use AllowN
instead of WaitN
here? There's no reason to block; I think we just want to take accruedGrants
out of the bucket.
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.
The documentation does not specify whether callingAllowN
will deduct however many tokens have accrued before returning false
. I dug into the code and if there aren't N
tokens that have accrued, the request is rejected and the bucket is not emptied. We must use WaitN
.
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.
Hmm.. that's really annoying. @fabioberger are we confident that there is no situation where this could block?
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.
Yes, I am confident this should never block. When we instantiate the rate limiter, we drain the bucket so that the number of accrued grants is theoreticalGrantsAccrued
- grantedInLast24hrsUTC
(where the theoretical grants accrued is calculated from the time elapsed since the start of the UTC day interval). Therefore the grants accrued left to be drained will be maxRequestsPer24Hrs
- grantedInLast24hrsUTC
.
…tadata collection
…proceed with Eth JSON-RPC requests
…go-routines spawned by the RateLimiter
…s with the RateLimiter
…it spawns have exited
84d98ea
to
afe35fa
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.
Just a few outstanding comments.
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.
Approved after CI passes
Currently, the number of Ethereum JSON-RPC requests a node makes scales with the number of orders being discovered. Instead, we want there to be a max cap, and if it is reached, have the node wait for more orders to accumulate before making the next RPC request.
There are two distinct caps, a per 24hr UTC time window cap, and a max per second cap. Both default to the Infura free-tier settings and are configurable by node operators.
Remaining TODOs:
stats
response