You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some RPCs cannot be batched. It would be nice to be able to force a send() to only contain one request instead of using batchMaxSize = 1 on the provider.
Maybe something like sendImmediate() (same arguments as send()) except just calls _send() directly and increases #nextId
This can be accomplished currently using _send() and constructing a JsonRpcPayload and handling the JsonRpcResult | JsonRpcError result but the #nextId doesn't get updated.
Code Example
awaitprovider.sendImmediate('eth_getProof', ...)// alternative idea #1provider.nextId();// expose the incrementer// alternative idea #2:awaitprovider.flushDrain();// clears timer and flushes payloadsawaitprovider.send('eth_getProof', ...)awaitprovider.flushDrain();// not guaranteed that payloads.length = 1
Why RPC methods cannot be batched? Is that specified in the documentation?
The goal of a JsonRpcProvider is to abstract much of this away from developers and keep a nice clean interface, but requiring a bunch of low-level calls would make the interface very difficult to describe.
My current suggestion for this would be to keep two instances of providers; one that is used normally and one that is "batchless" by setting maxBatchCount to 1, since it seems it is only commands sent using the lower-level .send?
For example, Linea does not handle batched eth_getProof, even [{...}] (a single request in a batch)
When I control the stack, I agree, I can just use 2 providers and this is a non-issue, but almost all tooling/middleware/etc, I don't have that option, I'm given a provider that someone else created, then what? I can't modify batchMaxSize and I can't access #nextId, hence this issue.
Now that I look a bit closer, I think I could switch on the type of provider and create a temporary batchMaxSize = 1 provider by cloning _getConnection() if the provider is HTTP. I guess if it's HTTP I can just use id = 1 and otherwise batching isn't supported. I think that's what my code essentially does.
Isn't the above function general and abstract? It simply gives the developer the ability to bypass the send queue. The code above is valid implementation except it cannot update the internal private state. Here is a more complete solution that triggers all of the appropriate events.
Describe the Feature
Some RPCs cannot be batched. It would be nice to be able to force a
send()
to only contain one request instead of usingbatchMaxSize = 1
on the provider.Maybe something like
sendImmediate()
(same arguments assend()
) except just calls_send()
directly and increases#nextId
This can be accomplished currently using
_send()
and constructing aJsonRpcPayload
and handling theJsonRpcResult | JsonRpcError
result but the#nextId
doesn't get updated.Code Example
Possible implementation:
The text was updated successfully, but these errors were encountered: