Setting status code/headers from api routes in Netlify functions does not work

[yoshi-monster]

I've tried setting a custom Content-Type header to add ActivityPub support to my website. Mastodon (one of the most popular implementations) requires a Content-Type of application/activity+json to be set on the responses. Unfortunately, it seems like none of the headers sent from Elm make it out to Netlify. Further testing revealed that none of the headers nor the status code is correctly sent. Instead, the function always responds with a status code 200 and a Content-Type of text/plain. (Netlify's default)

Since this works using elm-pages dev, I suspect that the problem might be in the Netlify adapter, specifically I think it might be confused about the response and body types.

Here is a snippet from my Netlify logs:

Aug 12, 02:37:58 AM: 26a70908 INFO   {
Aug 12, 02:37:58 AM: 26a70908 INFO   kind: 'api-response',
Aug 12, 02:37:58 AM: 26a70908 INFO   is404: undefined,
Aug 12, 02:37:58 AM: 26a70908 INFO   statusCode: 200,
Aug 12, 02:37:58 AM: 26a70908 INFO   body: {
Aug 12, 02:37:58 AM: 26a70908 INFO   body: '{"subject":"acct:[email protected]","aliases":["https://joshi.monster/.activitypub/actor"],"links":[{"rel":"self","type":"application/activity+json","href":"https://joshi.monster/.activitypub/actor"}]}',
Aug 12, 02:37:58 AM: 26a70908 INFO   statusCode: 418,
Aug 12, 02:37:58 AM: 26a70908 INFO   headers: { 'Content-Type': [Array], 'X-Custom-Test': [Array] },
Aug 12, 02:37:58 AM: 26a70908 INFO   kind: 'server-response',
Aug 12, 02:37:58 AM: 26a70908 INFO   isBase64Encoded: false
Aug 12, 02:37:58 AM: 26a70908 INFO   }
Aug 12, 02:37:58 AM: 26a70908 INFO   }

From what I can tell from the code, this is the renderResult. To me, this looks suspiciously like the adapter then confuses the types of body and renderResult, since both have a kind and statusType field, but only the body has headers; this means that in the returned netlify response, multiValueHeaders is undefined! The statusCode on the outer object is always 200.

[adamdicarlo]

I think the output you're seeing is from this console.dir() line that was recently removed: ddd0b05

So while it's not exactly the renderResult, it is the data the renderResult is derived from, just a few lines later. Interestingly, the kind === "api-response" code path references response.body.body and response.body.isBase64Encoded, but tries to find headers and statusCode in response instead of response.body.

So this does look like an elm-pages bug to me. Unfortunately, it's in elm-pages itself (in inlineRenderCode) rather than in the adapter, so the adapter can't work around it.

@dillonkearns , is the fix to change the logic in inlineRenderCode to build api-response results completely from response.body, or is the nested response thing itself the bug?

[yoshi-monster]

I've spent a few hours, following the code to the places where these values come from. To me, it looks like there is a lot of type confusion going on - not only in Javascript, but also on the Elm side. I imagine this is mainly a result of the v2->v3 transition, just making things work for now.

A "proper" fix would likely involve just cleaning these things up. The main "offender" related to this issue is probably that ApiRoute.Response is just a type alias for Json.Encode.Value, so type information is lost very early in the call stack and as a result, the upper layers cannot easily copy the right fields.

This looks like a bigger refactor waiting to happen, so for now, I've just made a pull request for the change in inlineRenderCode.