-
Notifications
You must be signed in to change notification settings - Fork 69
Open
Description
This caused us a great headache, because we only could detect it after deploying to Azure. Since 1.0.31 something changed, that when you declare your durable activity functions inside nested classes like this:
public class someFunction
{
[FunctionName("someFunction")]
public async Task<List<string>> RunOrchestrator(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
var outputs = new List<string>();
// Replace "hello" with the name of your Durable Activity Function.
outputs.Add(await context.CallActivityAsync<string>("someFunction_Hello", "Tokyo"));
outputs.Add(await context.CallActivityAsync<string>("someFunction_Hello", "Seattle"));
outputs.Add(await context.CallActivityAsync<string>("someFunction_Hello", "London"));
// returns ["Hello Tokyo!", "Hello Seattle!", "Hello London!"]
return outputs;
}
public class Activities
{
[FunctionName("someFunction_Hello")]
public string SayHello([ActivityTrigger] string name, ILogger log)
{
log.LogInformation($"Saying hello to {name}.");
return $"Hello {name}!";
}
}
}The function.json for the nested function, someFunction_Hello, is totally missing from the ouput since SDK 1.0.31. This is the output of SDK 1.0.31 build:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 12/03/2020 14:00 bin
d----- 12/03/2020 14:00 someFunction
d----- 12/03/2020 14:00 someFunction_HttpStart
-a---- 11/03/2020 22:09 231 host.json
-a---- 11/03/2020 22:09 163 local.settings.json
-a---- 12/03/2020 14:00 94559 someFunction.deps.json
While SDK 1.0.29 does generate someFunctionHello's function.json, generating a correct output:
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 12/03/2020 14:01 bin
d----- 12/03/2020 14:01 someFunction
d----- 12/03/2020 14:01 someFunction_Hello
d----- 12/03/2020 14:01 someFunction_HttpStart
-a---- 11/03/2020 22:09 231 host.json
-a---- 11/03/2020 22:09 163 local.settings.json
-a---- 12/03/2020 14:01 94552 someFunction.deps.json`
We tried this on SDK versions 1.0.33 and 1.0.34 with the same wrong output. We hope we don't need to change our coding conventions because of this and the team can fix it.