locked
Function is executed in an invalid state. RRS feed

  • Question

  • A function created with C # direct (not csx, not precompile, "configurationSource": "attributes") is in an invalid state but it is executed.

    • Open https://portal.azure.com/ 
    • Select your Function App
    • Select [Functions] > [Function Name] > Manage
    • Cange Function State. to Disabled

    The version of Microsoft.NET.Sdk.Functions is 1.0.4.


    • Edited by hamamotsu Monday, October 2, 2017 3:08 AM
    Monday, October 2, 2017 2:58 AM

Answers

  • What you are experiencing is an expected behavior though not an ideal one. It is a bug in the portal experience. It has been fixed but not yet deployed to production.

    The Function runtime directly consumes metadata in the binary files of the pre-compiled functions. Here is sample of annotation for the disabled function.

    [TimerTrigger("0 */5 * * * *"), Disable()]

    This is the function.json generated by visual studio the above annotations.

    {
    "generatedBy": "Microsoft.NET.Sdk.Functions.MSBuild-1.0.2",
      "configurationSource": "attributes",
      "bindings": [
        {
          "type": "timerTrigger",
          "schedule": "0 */5 * * * *",
          "useMonitor": true,
          "runOnStartup": false,
          "name": "myTimer"
        }
      ],
      "disabled": true,
      "scriptFile": "..\\bin\\FunctionApp3.dll",
      "entryPoint": "FunctionApp3.Function1.Run"
    }


    The function.json generated by the precompiled functions is consumed by the portal and that is what is shown in the portal. When you change the disabled state of the function in the portal the disabled property is changed in the function.json but it is not consumed by the functions runtime. Hence it continues to execute.

    When you deploy it in disabled state, runtime is aware of it and honors it as expected.

    Here is the portal bug for reference https://github.com/Azure/azure-functions-ux/issues/1857



    • Proposed as answer by Naren Soni Monday, October 9, 2017 7:57 PM
    • Edited by Naren Soni Monday, October 9, 2017 7:57 PM
    • Marked as answer by hamamotsu Tuesday, October 10, 2017 2:52 PM
    Monday, October 9, 2017 7:56 PM

All replies

  • What you are experiencing is an expected behavior though not an ideal one. It is a bug in the portal experience. It has been fixed but not yet deployed to production.

    The Function runtime directly consumes metadata in the binary files of the pre-compiled functions. Here is sample of annotation for the disabled function.

    [TimerTrigger("0 */5 * * * *"), Disable()]

    This is the function.json generated by visual studio the above annotations.

    {
    "generatedBy": "Microsoft.NET.Sdk.Functions.MSBuild-1.0.2",
      "configurationSource": "attributes",
      "bindings": [
        {
          "type": "timerTrigger",
          "schedule": "0 */5 * * * *",
          "useMonitor": true,
          "runOnStartup": false,
          "name": "myTimer"
        }
      ],
      "disabled": true,
      "scriptFile": "..\\bin\\FunctionApp3.dll",
      "entryPoint": "FunctionApp3.Function1.Run"
    }


    The function.json generated by the precompiled functions is consumed by the portal and that is what is shown in the portal. When you change the disabled state of the function in the portal the disabled property is changed in the function.json but it is not consumed by the functions runtime. Hence it continues to execute.

    When you deploy it in disabled state, runtime is aware of it and honors it as expected.

    Here is the portal bug for reference https://github.com/Azure/azure-functions-ux/issues/1857



    • Proposed as answer by Naren Soni Monday, October 9, 2017 7:57 PM
    • Edited by Naren Soni Monday, October 9, 2017 7:57 PM
    • Marked as answer by hamamotsu Tuesday, October 10, 2017 2:52 PM
    Monday, October 9, 2017 7:56 PM
  • thank you for your answer.
    There is no help for a portal bug.
    I hope that the modified version will be deployed to production.
    Tuesday, October 10, 2017 2:55 PM