Handling Promise status if Supply fails after Promise is kept

[muraiki]

If the p6sgi response is a promise but the message body contained within it is a supply, shouldn't a failure in the supply after the promise has been kept technically invalidate the promise? However, since a promise should never change states after either being fulfilled or failing, we can't really do that.

My concern is that we're embedding something that doesn't have the same sense of finality as a promise in a promise. I guess if the promise is only up to the point of "we have enough info to begin a response" then this is fine. But I was conceiving of the promise as indicating something more like "the response is complete."

So I guess the real question is "what does keeping the response promise mean?" :)

[zostay]

The Promise brings along the completed headers and a followup Promise (as a Supply is essentially a chain of Promises) that the remainder of the message will be delivered when it is available. A failure in the body does cause a broken promise, but it causes a later one in the Supply.

One alternative I have considered is making the body as a whole a Supply. The first value emitted could be the status, the second the headers, and the remainder would values to render to the body (or a similar variation). It might be more elegant to go that way in some ways. However, I've stuck to the Promise -> Supply route so far because it sticks to the same basic feel of PSGI, which is not a very important consideration, and because it highlights the delivery of the header which is generally thrown out as a single small chunk ahead of the body which might stream for a long time.

[muraiki]

Ok, I understand now. This sounds good, thanks!

Before I realized there was a P6SGI in the works, I was also thinking of the "just a supply" approach. However, after seeing this I think that I prefer to get one value that has the response code, headers, and a supply for the body.

I feel like that would make it easier for chained middleware to do things like examine headers, because it only has to examine the list in the single promise it receives, instead of having to do something like "get the second item from this supply." And as you said, you generally want to send the response code and header before the body anyways.

[zostay]

Thanks for the feedback! That's a really good justification for it and you stated it better than I could have.

Please feel free to make any other suggestions. I'm up for discussing just about any change.