Azure-webjobs-sdk: Application Insights: response code for any trigger except Http returns 0

[TheeJamesLee]

https://github.com/Azure/azure-webjobs-sdk/blob/dev/src/Microsoft.Azure.WebJobs.Logging.ApplicationInsights/ApplicationInsightsLogger.cs#L200

Can we have this returning 200 for a successful function run and 500 for an unsuccessful function run, ie, exception thrown?

Linking Azure/Azure-Functions#245 and Azure/Azure-Functions#398 for reference.

[brettsam]

We made an explicit decision to have non-Http bindings return a 0 status code because they're not really Requests. We've been talking with the App Insights team about another 'Operation'-type of Telemetry that we could use besides Request, but that's still in discussion.

I'm curious what having 200/500 would get you -- does it allow for better default charting, etc?

[TheeJamesLee]

@brettsam okay, I see where you've come from. However I would argue that putting something on a queue for example is a request for it to be processed by a consumer - and because now 'depending' on what is reporting the request it may/may not have a status code (but it is marked as a successful request).

The above question came from someone else looking to 'set' the resultCode - so I am not alone in this and they may need it for some other reason - likely cross querying for more information that just the boolean. Sure 200 = true, 500 = false, but there are more numbers so allows further expansion :)

Personally, because I have a lot of flex over our querying the success/failure boolean on the request 'can' work, but by allowing a resultCode to be specified does allow us to report;

Queue item processed, but was bad data.

Currently;
resultCode = 0
success = false.
(Message moved to poison queue).

Could be (Either passed from function code, or if the function code itself didn't throw an exception... don't know - thinking outloud);
resultCode = 400
success = false.
(Message moved to poison queue).

.. If an actual exception is thrown;
resultCode = 500
success = false.
(Message moved to poison queue).

By utilizing the result code I have already been able to more accurately report 'why' a message will be in the poison queue. Bad data to process, or an internal exception thrown for example.

I don't think setting it to 0 makes use of an already well known property ... and for myself (so I'm sure someone else will be thinking this way) ... a request does not have to be generated by a direct call to action (ie http).

[fbeltrao]

Even functions with HttpTrigger are reporting the resultCode as "0".
See this: App Insights not recording response code when used with Functions V2