azure-functions-host icon indicating copy to clipboard operation
azure-functions-host copied to clipboard

Index deeply nested Functions as in Functions Host V2 (or document limitation)

Open davidmrdavid opened this issue 3 years ago • 1 comments

What problem would the feature you're requesting solve? Please describe.

The Function below does not get indexed (i.e recognized) in Functions V4, but was recognized in Functions V2.

namespace FunctionApp1
{
    public static class Function1
    {
        public static class Foo
        {
            [FunctionName("Function1")]
            public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
    ILogger log)
            {
                // ... shortened for brevity
                return new OkObjectResult(responseMessage);
            }
        }
    }
}

The problem is that "Function1" is declared inside a nested class. If it was declared in the top-level class, or at the level of the namespace, then it would get recognized.

Describe the solution you'd like

For the Functions Host to support indexing deeply nested classes, or to document this coding constraint.

Describe alternatives you've considered

N/A

Additional context

Durable Functions users implementing Durable Entities with its class-based syntax are prone to declaring deeply nested Functions. This is because our samples for class-based Durable Entities show the Function declaration already inside a class, and so users copy-pasting these samples need to ensure they're pasting the sample within the top-level namespace to ensure their Entity is recognized.

This was not a concern in Functions V2, where the deeply nested Functions were recognized, but it seems support got dropped in later versions. We would appreciate a decision on whether this style of Function declaration will be supported again in the future, so that we may adjust the Entities samples and docs accordingly.

Thanks!

davidmrdavid avatar Oct 06 '22 21:10 davidmrdavid

This issue needs to be re-validated and re-contextualized within the new layout of function metadata indexing given the introduction of worker-indexing.

satvu avatar Feb 21 '24 21:02 satvu