Timeouts for V4 Isolated Function Apps Per Function

I'm currently working on migrating several function apps from .NET Core 3.1 and .NET 5/6 (v4) to .NET 7 Isolated Function Apps using the new Function Service Worker. However, I've run into some issues during the process. Despite conducting some thorough searches, I haven't been able to find an acceptable resolution. Moreover, the few answers I did manage to find suggest that there may be regression in functionality.

My function apps are organized by functionality, and include a range of queued, timer, and HTTP-triggered functions. However, not all of these functions have the same timeouts (using the timeout attribute provided by the webjobs package), and we don't want them to be equal either. For example, some functions should be allowed to run for up to 10 minutes, while others should not take that long and should terminate and retry earlier.

I have come across three suggestions. The first is to use the timeout in the host file. However, this would mean that every function runs with the same timeout, which is not what we want. The second suggestion is to divide the functions into separate apps based on timeouts. However, this approach seems unfeasible, as it would require grouping functions together by timeout instead of by domain/functionality. Lastly, we could write a custom attribute that attempts to replicate the functionality of the previous attribute which im not even sure is possible yet.

Therefore, the question or issue at hand is what is the expected behavior for this feature? Was it intentional to regress its functionality? Is there a specific reason why this functionality is no longer offered, either through attributes or JSON files? Or am I simply overlooking something that would enable me to still achieve this?

Start by reviewing the Function Service Worker behavior and the webjobs timeout attribute described in the issue, then compare it with the host-file configuration. Done means determining whether V4 isolated apps support distinct timeouts per function and documenting the supported behavior or the required change.

Written by the indexing model from the issue text.