repoze.retry does not work with repoze.tm2-2.0b1

[stephan-hof]

Sorry for abusing the github Issues, but I did not find a way to post on
http://bugs.repoze.org

With this change in repoze.tm2 repoze/repoze.tm2@4b68c7d
a pipeline with repoze.retry -> rempoze.tm2 does not work anymore.
repoze.retry raises a 'app must call start_response before returning' assertion.

The reason is that repoze.retry gets from repoze.tm2 a 'generator' object. The code within this generator, which is the whole logic of tm2, is not executed up to this point. The code within a generator is executed the first time iteration starts.
So 'start_response' is definitively not called.

I'm not sure if its a repoze.tm2 or repoze.retry problem.
I mean repoze.tm2 can be rewritten to call 'start_response' and still support streaming.
On the other side repoze.retry can be changed as well, to support retrying if a generator is returned.

I can work on this issue, but need a bit guidance for the way to go.

[tseaver]

I think we need to make 'repoze.retry' do the Right Thing(TM) when the application returns a generator: the WSGI spec[1] requires that middleware must allow 'start_response' to be deferred by its application until the first chunk of the app_iter is consumed.

I think the first task is to write a unit test using an application which does this (calling 'start_response' immediately before it yields the first chunk). We can then verify that we satisfy that case in 'repoze.retry' without breaking anything else.

[1] http://www.python.org/dev/peps/pep-0333/#specification-details, next to last paragraph

[tseaver]

A unit test (failing, for now):

https://gist.github.com/tseaver/5746072