Thanks for the amazing work on this package @metachris and also @TitanBuilder for adding the broadcaster middleware in #19.
We are currently trying to integrate flashbotsrpc into stackup-bundler to enable broadcasting of ERC-4337 UserOperations to a list of known builders. I ran into some issues with error handling which I think this PR would fix.
In a success scenario, if I broadcast a batch to 3 builders with no errors, I would expect a response like this:
But in the case where one builder returns an error, we end up with a response like this:
{BundleResponse:{BundleHash:} Err:...}
{BundleResponse:{BundleHash:} Err:unexpected end of JSON input}
In this case the error from a bad builder is causing all the successful responses to be thrown away and we are adding an additional response with the error unexpected end of JSON input. Ideally the response should look like this:
Thanks for the amazing work on this package @metachris and also @TitanBuilder for adding the broadcaster middleware in #19.
We are currently trying to integrate flashbotsrpc into stackup-bundler to enable broadcasting of ERC-4337 UserOperations to a list of known builders. I ran into some issues with error handling which I think this PR would fix.
In a success scenario, if I broadcast a batch to 3 builders with no errors, I would expect a response like this:
But in the case where one builder returns an error, we end up with a response like this:
In this case the error from a bad builder is causing all the successful responses to be thrown away and we are adding an additional response with the error
unexpected end of JSON input
. Ideally the response should look like this:The reason for this, which I address in the PR, is because:
json.Unmarshal
an error response with a nilmsg
which is causing the additionalunexpected end of JSON input
error.