-
Notifications
You must be signed in to change notification settings - Fork 0
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
handle batch EVM requests #84
Conversation
847d788
to
29004a1
Compare
29004a1
to
94ec347
Compare
|
||
// fakeResponseWriter is a custom implementation of http.ResponseWriter that writes all content | ||
// to a buffer. | ||
type fakeResponseWriter struct { |
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.
bufferedResponseWriter
a la https://pkg.go.dev/bufio?
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 that's for buffered read/writing. as in, ensuring writes happen in chunks no bigger than a certain size, not for just writing to a bytes.Buffer
. i think the buffering capabilities are overkill for what's needed here
proxy service responds 413 if it receives a request with >ProxyMaximumBatchSize sub-requests
instead of arbitrarily sleeping and praying that the metric was created, wait for the metrics to be created. if the expected metrics are not created, the test will fail with a timeout.
Adds support for batch EVM queries.
Batch queries have bodies with a list of
EVMRPCRequestEnvelope
s instead of just one. Currently, these fail to decode and then skip the cache, skip metrics, and just get forwarded to the appropriate backend as-is.This PR handles decoding the batch requests and supports getting responses to their sub-requests from the cache. To do this, it adds two new middlewares:
DecodeRequestMiddleware
- a rewrite ofRequestLoggingMiddleware
. now attempts to parse incoming request as a[]*EVMRPCRequestEnvelope
if it fails to parse as*EVMRPCRequestEnvelope
. Forks the middleware sequence if the request is a batchBatchProcessingMiddleware
- pulls the batch request out of the context, separates into individual requests that can leverage response caching (and metrics). Then, it concurrently makes the individual requests through the same middleware sequence as the current single request processing. All the individual responses are combined back into a single response to the client.For minimal changes to existing architecture, the BatchProcessingMiddleware just makes use of the exact same middleware sequence as the handling of single requests. Optimizations can be made in the future to recombine sub-requests that will be directed to the same backend if performance is a problem (we have metrics to now to know!). I excluded those changes for now to minimize potential impact to existing single request response flow.
Opening for code review, will not merge until architecture docs have been updated.