In a .csx function, change return to retur to break it, and click Save and Run. All you get is:
2018-04-19T21:40:44.047 [Error] System.Private.CoreLib: Exception while executing function: Functions.HttpTriggerCSharp1. Microsoft.Azure.WebJobs.Script: Script compilation failed.
2018-04-19T21:40:44.048 [Error] Executed 'Functions.HttpTriggerCSharp1' (Failed, Id=a7042c3f-6406-4be9-a780-b7555cfbf943)
It's missing all the detailed compile error info.
@fabiocav Is this a runtime issue, or is it something about the portal not consuming the structured error log when running against linux?
This is a blocker for BYOF portal development.
@dariagrigoriu I see you removed it from the backlog.. do you have someone working on this?
We now understand what's going on.
On Windows, we only log the compile error at the time the .csx file is saved, and never when it's run.
But on Linux, where we don't have reliable file change notification, @ahmelsayed implemented a workaround where each time a file is saved in the Portal, he restarts the host. As a result, the code path that logs errors on file saves (based on notifications) never takes place, and the errors never make it to the log.
The current behavior is by design, the goal being that on the invoke/run path we don't want to output the usually voluminous compilation errors on every invocation. E.g., consider an EventHub function processing LOTS of events. If a compilation error is introduced, every invocation might be spewing tons of compilation output, stack trace, etc. So we did work to suppress this on the invoke path.
What we can do to address this is when in Debug mode we can output the full error info. This makes sense because Debug Mode is enabled only when the portal is connected, and in that case you're developing and want to see errors.
@mathewc that sounds good. If we do this, let's make sure that we don't end up displaying them twice on Windows: once from the Save and once from the Run.