[Seaside-dev] Initial Request Failure on Retry

[Ken Treis]

We have build something using the Seaside-Rest add-on, and everything works beautifully in GemStone until a transaction conflict triggers a retry -- at which point we get a 404 rather than the expected response.

We tracked the issue down to the WAPathConsumer, which keeps track of the path (destructively) as the request is being resolved. Its state isn't being reset before the request is retried, so subsequent requests are effectively tried against a different path.

We've fixed in our home-grown Zinc streaming adaptor by adding the following line just before we retry:

> aRequestContext consumer initializeWith: aRequestContext request url path copy


This is admittedly a dreadful encapsulation violation. Ideally, maybe we'd implement something like #reset on WARequestContext. There is some other internal state (like `handlers`) that should probably be reset too, though I think in practice the use of #ensure: in #push:during: empties out the handlers collection before handling is retried.

Alternately, we could perhaps make WAPathConsumer non-destructive and implement #reset there. It already acts a bit like a stream, so a #reset method would not be too out of place there.

Thoughts?

--
Ken Treis
Miriam Technologies, Inc.