From @fabiocav on March 26, 2018 17:2

From @SimonGuo009 on March 26, 2018 10:10

Portal Environment: https://ms.portal.azure.com
Browser: English/Chrome
Runtime Version: 2.0.11651.0 (~1) (Private Site Extension)

Please refer to the snapshot:

Repro steps:

1. Open or create a function app.
2. Create a function using BlobTriggerWithParameters-JavaScript template.
3. Upload a 0 byte file in the corresponding blob.
   4.Verify logs for the function.

Copied from original issue: Azure/azure-functions-ux#2467

Copied from original issue: Azure/azure-webjobs-sdk#1645

Need to maintain only one version of: azureFunctions

Issue
Failing to load a function throws an exception that crashes the worker because it's not handled.
The functions CLI retries starting the worker up to 2 times more always with the same issue.

Expected behaviour
The worker doesn't crash but still shows the appropriate error message for the failing function.
Properly resolved functions loaded under the same worker will still work.

Reproduce steps
Create a function that does not export a function
E.g.:

module.exports = {}

Known test failures:

• - Scenario_RandGuidBinding_GeneratesRandomIDs : Need to figure out how handle integers. Should we add number type to proto TypedData?
• - BlobTriggerToBlobTest : Need to investigate why bindingdata is missing blobType
• - PromiseApi_Rejects : Need to update host to throw an error with the statusResult for the invocation is "Failure"
• - SharedDirectory_Node_ReloadsOnFileChange: Need to update host and worker to handle file change events
• - TimeoutTest_SyncFunction_Node : Need to update host and worker to handle timeout events
• - webhooks

Sending an message that was too caused an uncaught exception to be thrown and the worker to shut down. Afterwards, the host shutdown. This may be due to an unrelated timeout error, but should be verified.

Worker xxxx encountered event stream error: { Error: Received message larger than max (5852896 vs. 4194304)
Worker xxxx uncaught exception: { Error: Received message larger than max (5852896 vs. 4194304)

grpc Javascript enum issue

It would be nice to have verbose logging in the language worker that can be requested by host.

For example, we remove HTTP header values that evaluate to null, and it would be nice to log when we do that for better debugging.

Investigate if some of the properties (raw_response, raw_body can be simplified)

item.Value is of type IDictionary<string, object>, but not IDictionary<string, string>.

i.e. api/nodehttp/{id:int}

Need to figure out better way than to create new input key: webhookReq

also, solution root may be better than package dir + output path for installation

See details on the original issue reported here: Azure/azure-functions-host#2768
Initial fix was to update RpcHttp proto file to <string, TypedData> dictionary. According to HttpSpec header values are only valid ASCII characters. Need to fix NodeJS worker to convert to strings before sending message to functions host

Repro:

Send a message greater than 4MB in size. Host will crash with no errors to logs.

Expected behavior:

Host should gracefully handle unhandled exceptions. It should attempt to log them to the host and stderr.

headers field in RpcHttp is updated to <string, object> pairs. ToRpcHttp and FromRpcHttp methods in Converters.ts need to be updated.

NodeLanguageInvoker in functions host handles invocations for Node. Need to refactor this handle Javascript and Java invocations

We should produce a typings file for our externally facing APIs

Update: https://www.npmjs.com/package/@azure/functions

Repro Steps

1. I used the this snapshot of the host code
2. I created a Functions App on Azure portal, and uploaded the local-published zip to it using Kudu
3. I tried to start my Java worker, but it failed to connect to the server
4. I dumped the logs, and find the related messages below:

2017-06-19T23:40:35.085 address 127.0.0.1 .
2017-06-19T23:40:35.112 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at System.Net.Sockets.TcpClient.Connect(IPEndPoint remoteEP)
   at Microsoft.Azure.WebJobs.Script.Rpc.Utilities.IsTcpEndpointAvailable(String addressArgument, Int32 portNumber, TraceWriter systemTraceWriter) in D:\Java\azure-webjobs-sdk-script\src\WebJobs.Script\Rpc\Utilities.cs:line 36
2017-06-19T23:40:35.112 Not listening on port 50051.

5. I changed the port to 55555, everything just works fine

Run invoker tests in the nightly builds

Currently it "literally just craps all over itself" (Brady Gaster)

Repro:
Use Node 9. try to debug in VS Code.

Running NodeE2E tests shows following warning:
(node:25816) Warning: Possible EventEmitter memory leak detected. 11 uncaughtException listeners added. Use emitter.setMaxListeners() to increase limit

Needs investigation

We should get some tests in place similar to what we had in v1.x Functions for the Edge.js based interop layer.

As an example, the entry point for our v1.x Node unit tests (Mocha tests) is here: https://github.com/Azure/azure-functions-host/blob/v1.x/runNodeTests.cmd. Mocha unit test file here: https://github.com/Azure/azure-functions-host/blob/v1.x/test/WebJobs.Script.Tests.Integration/TestScripts/Node/functions.tests.js. When making changes to the Node interop layer, it was easy to run these locally from the command line.

Follow instructions in the repo's readme:
https://github.com/Azure/azure-functions-language-worker-protobuf

Following function fails in V2
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World!');
}).listen(8080);

Need to investigate if this is supported in V1.
In V2, as reported here Azure/azure-functions-host#2321 function fails without any error.

If you export a promise instead of a function and call context.done you end up with the wrong error message:
Error: 'done' has already been called. Please check your script for extraneous calls to 'done'.
Where the error should have read:
Error: Choose either to return a promise or call 'done'. Do not use both in your script.
It would seem that the isPromise parameter in Context.ts is never being set to true
Which ends up causing the wrong message to be reported by the worker.
Also as far as I could tell the documentation is nowhere clear on what's the expected behavior when exporting promises and this may be confusing to users.

From @danfsd on May 21, 2018 18:24

Request's body is a <Buffer> instead of object in Azure Function's Runtime Beta. This works fine in the Cloud (which I suppose is running Runtime 1.x

Repro steps

Try to run the boilerplate Javascript code in the Runtime beta:

module.exports = function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');
    context.log(context.req.body.name);
    if (req.query.name || (req.body && req.body.name)) {
        context.res = {
            // status: 200, /* Defaults to 200 */
            body: "Hello " + (req.query.name || req.body.name)
        };
    }
    else {
        context.res = {
            status: 400,
            body: "Please pass a name on the query string or in the request body"
        };
    }
    context.done();
};

Expected behavior

The context.log(context.req.body.name) should log:

2018-05-21T17:41:12.509 [Info] daniel

Actual behavior

Instead, it's logging:

<Buffer 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 33 30 38 32 35 30 31 33 36 35 39 30 36 31 38 38 37 30 38 32 36 32 ... >

Known workarounds

This scenario works just fine under the Runtime 1.x running on Azure Functions.

Copied from original issue: Azure/azure-functions-host#2875

Add test setting the response headers of different types "stringHeader" , 123
PR #79

Worker / Function load related

resolved by https://github.com/pragnagopa/azure-webjobs-sdk-script/pull/8

It's just like JavaScript, but with Types.

Update grpc version to address:

• grpc/grpc-node#225
• Azure/azure-functions-host#2758

• Add verbose and info level system logs with option to turn on verbose logging when debugging

Although Node 8 is under long-term support, Node 9 is current. Any install via brew or chocolatey will default to Node 9, which creates a bad experience for local developers that install node for the first time on a machine and must downgrade to 8.

UPDATE: node 10 just released

"result" of GRPC StatusResult message must be string (not exception). We should not be setting an exception object to be "result", which expects a string (here:

Similar issues may be occurring where grpc message components have mismatched types.

Related to: Azure/azure-functions-host#2510

Update package.json to include exact version of grpc we depend on

Add worker.config.json file as described here.

Azure/azure-functions-host#1702

From Azure/azure-functions-host#2305

Need to not send back just a json response if the body is missing.

https://github.com/Azure/azure-functions-nodejs-worker/blob/dev/src/Converters.ts#L18-L20

"What Lambda is doing is looking for your event loop to be empty, and if it is, stopping the execution."

We could allow users to configure settings to more defensively look for coding errors of not calling done/next by looking at the event loop and seeing if we should stop execution but aren't.

This could prevent users from seeing functions that just hang.

Original request: https://stackoverflow.com/questions/47584690/azure-function-hangs-on-error

Currently we convert the context.bindings object which still has input bindings attached

Assuming there are no issues with in/out