404 error [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] on linux container durable function app

[vigouredelaruse]

the attached docker file is used to generate a container from a function that works well in linux and windows appservice plans. at some point, perhaps due to Something I Did, the http triggers began throwing 404 in East Us on a B1 Linux App Svc. Any ideas?

DOCKER

FROM mcr.microsoft.com/azure-functions/dotnet:3.0 AS base
WORKDIR /home/site/wwwroot
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:3.1-buster AS build

WORKDIR /src
COPY ["mainproj.csproj", "etc/"]
COPY ["projectinclude/etc.csproj", "projectinclude/"]
COPY ["projectinclude/etc.csproj", "projectinclude/"]

RUN dotnet restore -r "linux-x64" "projectinclude/etc.csproj"
COPY . .
WORKDIR "/src/notreallyetc"
RUN dotnet build -r "linux-x64" "etc.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish -r "linux-x64" "etc.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /home/site/wwwroot
COPY --from=publish /app/publish .

ENV AzureWebJobsScriptRoot=/home/site/wwwroot
AzureFunctionsJobHost__Logging__Console__IsEnabled=true

[cgillum]

Since the 404 is coming from an HTTP trigger function, the problem likely isn't related to Durable Functions. I would suggest taking a look at your logs in Application Insights (assuming you have that configured). At app startup time, there should be some information about what functions were found. Make sure that all the HTTP trigger functions you expect to see are there. If not, check to make sure your app payload includes them and that you don't have any app settings, etc. that might be disabling your HTTP triggers.

[vigouredelaruse]

ok thanks i'll investigate it as a routing issue unrelated to durable functions. also i stopped running different builds of the same function against the same storage account. wondering if this can leave your future deployments in a broken state unless you delete 'something'

while i have you is there any difference between deploying to a windows app service (non-docker) vs a linux app service (non-docker)?

specifically

• does PublishReadyToRun = true work 'anywhere'? does it break docker builds?
• what's the recommended setting for < Platforms />, if any?
• is there any good reason why dependency injection should work on a windows app svc plan and not on a linux app svc plan function deployment? maybe due to the runtimeidentifier for instance?

thanks for any comments

[cgillum]

does PublishReadyToRun = true work 'anywhere'? does it break docker builds?

Looking at this documentation, it looks like ready-to-run produces platform specific binaries. For that reason, you probably need to publish from an OS that matches the OS you're deploying to.

what's the recommended setting for < Platforms />, if any?

I'm not really familiar with that setting. I know there is a similar <TargetPlatform> setting described here for deciding between AnyCPU, x64, or x86 but I'm not sure if that's the same as what you're describing. More useful-looking info can be found here. I wouldn't set it at all unless you know for sure that you need it. The default AnyCPU target platform can run on any OS.

is there any good reason why dependency injection should work on a windows app svc plan and not on a linux app svc plan function deployment? maybe due to the runtimeidentifier for instance?

Dependency injection should work equally across different platforms. The only reason I can think of where it might behave differently is if you're injecting a service that has some platform-specific dependencies and you're deploying on an incompatible platform.

[vigouredelaruse]

the root cause for this has been identified and documented over here Azure/azure-functions-docker#433

the issue was missing http extension declaration in host.json unidentified but localized to the specific failing app service. fix was to spin up a new function app container svc and redeploy and duplicate config. so this one is a mystery