Plugin causes 502 server errors for GraphQL functions

[AustinGil]

Description

I have a Serverless GraphQL endpoint using apollo-server-lambda and I'm trying to add a serverless route that returns a PDF. For that, I think I need to define the "Binary Media Types" in AWS. And do accomplish that, Im using this plugin, but this causes some issues. With the plugin disabled, the GraphQL endpoint works, but the PDF endpoint does not. When I enable the plugin, the PDF works, but the GraphQL endpoint experiences some strange internal server error.

Package details

"apollo-server-lambda": "^2.9.0" "serverless-apigw-binary": "^0.4.4"

Expected behavior

I expect the serverless plugin to integrate without causing a server error.

Actual behavior

When I enable the plugin, the GraphQL endpoint returns message in the GraphQL playground:

{
  "error": "Response not successful: Received status code 502"
}

And for any query or mutation:

{
  "error": {
    "message": "Internal server error"
  }
}

Exploring the logs returns this error message:

2019-10-22 17:23:42.786 (-07:00)	8fa3224b-aeb8-48e9-b955-8d2ba05eede3	ERROR	Invoke Error	{"errorType":"SyntaxError","errorMessage":"Unexpected token e in JSON at position 0","stack":["SyntaxError: Unexpected token e in JSON at position 0","    at JSON.parse (<anonymous>)","    at graphqlHandler (/var/task/node_modules/apollo-server-lambda/dist/lambdaApollo.js:24:24)","    at /var/task/node_modules/apollo-server-lambda/dist/ApolloServer.js:112:16","    at Runtime.exports.graphql [as handler] (/var/task/src/index.js:50:12)","    at Runtime.handleOnce (/var/runtime/Runtime.js:66:25)","    at process._tickCallback (internal/process/next_tick.js:68:7)"]}

[export-mike]

same issue with me I'm posting a json object to the function for it to populate a pdf I'm generating same problem. SyntaxError: Unexpected token e in JSON at position 0 in my cloudwatch logs

[AustinGil]

@export-mike I don't have an ideal solution, but when I deploy my PDF function into a completely different serverless.yml file it works, so maybe that is an option for you.

[export-mike]

so we were not using this in a graphql context but i think graphql is not the issue.

for me it was using the correct "Accept" headers for "application/pdf"

[AustinGil]

Ah yeah, you gotta remember to put that part in.

[eurobob]

so we were not using this in a graphql context but i think graphql is not the issue.

for me it was using the correct "Accept" headers for "application/pdf"

@export-mike can you elaborate on this please? I'm having a similar issue for multipart/form-data requests, but don't know where to set these Accept headers

[export-mike]

In the request from the client