Azure-functions-host: malformed message invocationResponse.outputData.data.http.body.object expected

[antstanley]

Currently using the v2 Function App version locally to debug on my Mac and it keeps succeed with the following information message and not responding with correct response.

info: Worker.Node.f52ff43c-b7d2-4b78-a3b2-02db6e1302e2[0]
      Worker f52ff43c-b7d2-4b78-a3b2-02db6e1302e2 malformed message invocationResponse.outputData.data.http.body.object expected
info: Worker.Node.f52ff43c-b7d2-4b78-a3b2-02db6e1302e2[0]
      (node:91399) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id:2): invocationResponse.outputData.data.http.body.object expected

I reinstalled azure-functions-core-tools and this info message disappeared, but the function still succeed with a no response.

Upon inspecting the context object, the correct context.res.body data, but when context.done is called context.res changes to null

The function is a GraphQL server, based on the Apollo Azure Functions project (it's a fork of that as the original project has some problems). This worked for me three weeks ago, but coming back to the project on a fresh install it's no longer working.

When I upload this to Azure and run it on the v1 runtime (which is where I want it to run in production until v2 is stable) it works perfectly.

Language: NodeJS
Version: 8.9.4
Functions tools: [email protected]

Please let me know if you need anything else. My project repo is private, so I'll have to create a sanitised version to share if you need it.

[dynamicwebpaige]

Bumping this item for visibility. Can we get it added as a product issue / attempt to replicate?

[christopheranderson]

Nothing is different in the last few months for our Node.js worker, so the three weeks ago thing is interesting. We don't do anything to muck with the context object once done is called, so that's a weird behavior. Here's the source code for the done callback: https://github.com/Azure/azure-functions-nodejs-worker/blob/dev/src/WorkerChannel.ts#L96

Do you have a repro I can run?

[antstanley]

FWIW I don't think it's an issue with the worker process... I stepped through the execution and it handed off the correct response to the functions runtime. The issue happened on my machine and a colleagues machines, both MacOS... I'll get a public repo together for you to diagnose.

[antstanley]

Here is a demo repo... https://github.com/antstanley/azure-functions-graphql

2 functions

• graphql (graphQL server)
• graphQLPlay (Graphiql playground)

go to the /api/graphQLPlay url to test... it should return the Graphiql web app via a browser

Neither respond correctly with the local Azure Functions beta runtime on my Mac, but run perfectly in Azure on the v1 run time... they used to work on my mac 😢

Invoking the runtime via VS Code Debug ... my VS code workplace settings are in this repo. I have the default global VS Code settings.

dotnet version 2.1.101
Azure Functions Core Tools (2.0.1-beta.23)
Function Runtime Version: 2.0.11587.0

Mac OS X 10.13.3

[christopheranderson]

Cool, thanks for the repro. Me or Marie will take a look.

[christopheranderson]

Notes from repro:

• Modules are in each function folder, can put them at the base of your project and they'll share dependencies
• When I start it locally on v2 (windows), it returns a 406 status code.
• When I start it locally on v1 (windows), it works!
• When I remove the header, it works on v2 (this is another sign its an issue in the Functions host)
• Given that this is probably our host trying to do too much smarts, I set the "isRaw" flag to true. This worked

    GraphiQL.resolveGraphiQLString(query, options).then(function (graphiqlString) {
        let result = {
            status: 200,
            isRaw: true,
            headers: {
                'content-type': 'text/html',
            },
            body: graphiqlString,
        };
        callback(null,result);

Workaround:

• Set the isRaw flag to true on responses to have our content negotiation stuff turned off.

[christopheranderson]

@mhoeger is gonna take over on this one. We think we have a solution that is non-breaking that doesn't force folks to set the raw flag. She'll describe it in another issue, I think, and link to this.

[antstanley]

Thanks Chris! Glad I wasn't going mad... Will set isRaw for now while you get your fix implemented.

On the modules in each function thing, there is a build step I'm using on my private project that bundles the individual functions into single js file using Webpack, which I didn't move across to the public repo.

[mhoeger]

Closing as this is tracked by #2552 and there is an unblocking workaround.

This is a regression in V2, will be fixed soon :)