inputBufferSize cannot be configured right now but you can just retry the command (after letting some time pass). It probably doesn’t make a lot of sense to increase the queue size if the system cannot handle the pressure.
In case of burst loads in can make sense to configure the system to gracefully handle such peaks. Generally, I’d argue there should be some (even if convoluted) way to configure any setting, the alternative of hardcoding and baking it into the binary is not optimal.
Of course, I agree that it should be tunable. What I’m suggesting is that for a migration, which is a planned event, handling backpressure is a more sustainable solution than increasing the queue size, which could also lead to unpredictable performance fluctuations and increased latency, possibly up to the point where commands start timing out due to a long stay in the queue.
We can override it in our codebase due to our sandbox’s legacy as a much deeper fork than it is today…we found cranking that up to 51,200 from 512 didn’t lead to any adverse performance effects (other than everything working). I don’t disagree that handling backpressure is a thing we can do, but I also suspect that limits like this are artificially throttling the parallelism that sandbox is capable of in some cases.