{"action":"created","issue":{"url":"https://api.github.com/repos/zostay/P6SGI/issues/2","labels_url":"https://api.github.com/repos/zostay/P6SGI/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/zostay/P6SGI/issues/2/comments","events_url":"https://api.github.com/repos/zostay/P6SGI/issues/2/events","html_url":"https://github.com/zostay/P6SGI/issues/2","id":104278480,"number":2,"title":"Handling Promise status if Supply fails after Promise is kept","user":{"login":"muraiki","id":1663443,"avatar_url":"https://avatars.githubusercontent.com/u/1663443?v=3","gravatar_id":"","url":"https://api.github.com/users/muraiki","html_url":"https://github.com/muraiki","followers_url":"https://api.github.com/users/muraiki/followers","following_url":"https://api.github.com/users/muraiki/following{/other_user}","gists_url":"https://api.github.com/users/muraiki/gists{/gist_id}","starred_url":"https://api.github.com/users/muraiki/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/muraiki/subscriptions","organizations_url":"https://api.github.com/users/muraiki/orgs","repos_url":"https://api.github.com/users/muraiki/repos","events_url":"https://api.github.com/users/muraiki/events{/privacy}","received_events_url":"https://api.github.com/users/muraiki/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-09-01T14:26:45Z","updated_at":"2015-09-01T15:21:29Z","closed_at":null,"body":"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.\r\n\r\nMy 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.\"\r\n\r\nSo I guess the real question is \"what does keeping the response promise mean?\" :)"},"comment":{"url":"https://api.github.com/repos/zostay/P6SGI/issues/comments/136758378","html_url":"https://github.com/zostay/P6SGI/issues/2#issuecomment-136758378","issue_url":"https://api.github.com/repos/zostay/P6SGI/issues/2","id":136758378,"user":{"login":"muraiki","id":1663443,"avatar_url":"https://avatars.githubusercontent.com/u/1663443?v=3","gravatar_id":"","url":"https://api.github.com/users/muraiki","html_url":"https://github.com/muraiki","followers_url":"https://api.github.com/users/muraiki/followers","following_url":"https://api.github.com/users/muraiki/following{/other_user}","gists_url":"https://api.github.com/users/muraiki/gists{/gist_id}","starred_url":"https://api.github.com/users/muraiki/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/muraiki/subscriptions","organizations_url":"https://api.github.com/users/muraiki/orgs","repos_url":"https://api.github.com/users/muraiki/repos","events_url":"https://api.github.com/users/muraiki/events{/privacy}","received_events_url":"https://api.github.com/users/muraiki/received_events","type":"User","site_admin":false},"created_at":"2015-09-01T15:21:29Z","updated_at":"2015-09-01T15:21:29Z","body":"Ok, I understand now. This sounds good, thanks!\r\n\r\nBefore 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.\r\n\r\nI 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."}}