Fix: add backoff to driver.go alt-da put request fail logic
Description
When the put request to the da-server fails, it the batch submitter puts back the frames into their respective channel builder, and returns nil (instead of err). This was probably added to allow the driver to retry sending the blob to the server immediately, without having to wait until the next poll. However, this is very bad behavior as clients should typically linear or exponential backoff when retrying requests, which this code doesn't do.
** Solution **
Returning the err will make the for loop return, and wait for the next poll before retrying to send blobs to the da server.
Tests
Have not added any tests. This is a fairly simple change. It might have unintended consequences though, so I'd be happy to know if there's some tests I should run.
Additional context
Here is my op-batcher sending a gazillion (500 returning) requests in a very short amount of time to the eigenda-proxy (our da-server):
Metadata
- Fixes #[Link to Issue]
I would like to build a little more confidence in this being the solution given the work going on in https://github.com/celo-org/optimism/pull/213 before merging
@tynes this is not related to parallel blob submission. This is just fixing a problem with the current sequential submission implementation. But if you're saying that you'd prefer to wait until we have a parallel blob submission PR ready before merging anything at all, then that's also fine with me.
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days.