Failure to call .end() on the response object in an HttpEndpoint leads to confusing behavior

It would appear that if you don’t call .end() on the response object in the function that handles your cloud.HttpEndpoint when you make a request, you get a 502 error from API Gateway.

I was trying to write a brain dead simple hello world app and originally wrote

// Copyright 2016-2017, Pulumi Corporation.  All rights reserved.

import * as cloud from "@pulumi/cloud";

const app = new cloud.HttpEndpoint("hello");

app.get("/hello", async (req, res) => {
    res.write("Hello, world");
});

export let endpointUrl = app.publish().url.then(url => url)

This deploys correctly but you hit errors when you try to curl the endpoint. If you add a call to .end() after .write() then things work.

What’s even worse (maybe?) is that I found this impossible to debug. pulumi logs did not show me anything, the CloudWatch log group for the lambda did not show any errors (you could see events for start and stop each time you hit the endpoint). Pat, MattDR and I spent a bunch of time in the AWS console trying to send test events to the lambda and understand responses before I thought to go look at an existing application that had an HttpEndpoint and read the implementation.

[lukehoban]

Note that send and end are synonyms. We definitely need to add send as well - and that may help on the front end of this problem.

My primary concern is how we can make debuggability better on the backend of this - since that’s where we are likely to hit a larger class of issues with it being difficult to diagnose what’s happening during “expected” classes of failures in Node. Not sure what the answer is there though…

[lukehoban]

Unlikely we’ll make targeted improvements like this - more likely we’ll more broadly rethink this library.