HTTP2 does not resume the same stream that was blocked

	@markrwilliams reported
Trac ID	trac#9651
Type	defect
Created	2019-06-08 21:04:54Z

twisted.web._http2.H2Connection._sendPrioritisedData first finds a stream from the priority tree to work on, then checks if consumer is blocked. If it is, _sendPrioritisedData reschedules itself as a callback on the the _consumerBlocked Deferred. There's no guarantee that the stream popped off the priority tree when _sendPriortisedData will be the same stream.

The simple solution is check _consumerBlocked before looking for a stream that might not be used.

trac-id__9651 9651
type__defect defect
reporter__markrwilliams markrwilliams
priority__normal normal
milestone__None None
branch__ 
branch_author__ 
status__new new
resolution__None None
component__web web
keywords__h2 h2
time__1560027894126933 1560027894126933
changetime__1560027894126933 1560027894126933
version__None None
owner__None None

Start in twisted.web._http2.H2Connection._sendPrioritisedData and inspect how _consumerBlocked is checked and used. Ensure the callback resumes the same blocked HTTP/2 stream rather than selecting a different stream from the priority tree; done means the blocked stream is reliably resumed.