There is some connection/stream capacity management issue that leads to attempt to send a data frame larger than the available window. An attempt to account for the sent frame in this case leads to an assertion.
There was a previous attempt to fix this issue - on for a stream capacity. We still have seen the assert bei ng hit at the connection level.
It may be a good idea to treat this as an error and propagate it out - but there is no error path at this point and the caller context is murky, and creating a new error path is really quirky.
The previous attempt for a fix mimicked the code a few lines above that also seems to be dealing with the lack of allocated capacity - the approach is to re-queue the frame into the stream and continue. The stream is supposed to be rescheduled on new i/o, window update or capacity becoming available - it is not really obvious if condition will self resolve or some streams may become stuck, fingers crossed.
There is some connection/stream capacity management issue that leads to attempt to send a data frame larger than the available window. An attempt to account for the sent frame in this case leads to an assertion. There was a previous attempt to fix this issue - on for a stream capacity. We still have seen the assert bei ng hit at the connection level.
It may be a good idea to treat this as an error and propagate it out - but there is no error path at this point and the caller context is murky, and creating a new error path is really quirky.
The previous attempt for a fix mimicked the code a few lines above that also seems to be dealing with the lack of allocated capacity - the approach is to re-queue the frame into the stream and continue. The stream is supposed to be rescheduled on new i/o, window update or capacity becoming available - it is not really obvious if condition will self resolve or some streams may become stuck, fingers crossed.
The main goal is to produce some logs.