Azure function app wwwroot folder missing
I have an Azure Function app which is constantly returning 404 for all of the endpoints. The API configuration seems correct so the issue is with the function itself. It had been working fine until recently. The only thing that I have noticed which is strange is that when I compare the folder structure using Kudu, a working function app has a /home/site/wwwroot directory,
but my broken function app does not:
I think this has something to with my issue. I tried to manually create the folder and I get a 409 error.
The code is written in C# and deployments don't work using the azure pipeline as well as manually doing a deployment with
func azure functionapp publish <function app name> --dotnet
I noticed that the app setting WEBSITE_CONTENTSHARE was set to a value that was originally only on the staging slot, something like staging-asdf-fdsa, could that have caused the problem? I tried changing the value and restarted the function app but it didn't seem to make a difference
Does it seem like I am on the right path? Does anyone know why this folder would be gone? I'm wondering if an app setting that I had might have broken my function app when I was doing a swap between my staging slot and production slot.
If there's any additional info that would help please let me know and I will edit this question with it.
UPDATE
I was able to get it to properly create the wwwroot directory by toggling the WEBSITE_RUN_FROM_PACKAGE from 1 to 0, when I did my deployment, it switched it back to 1 and created the wwwroot directory.
The issue is that I still receive a 404 for a valid URL.
Found the root cause. I looked into the C# application that is running and I found that in Startup.cs, the api route suffix was being set. MS documentation is very confusing around this and the intention seems to have been to switch from /api to /api/<something>, and while it appears that worked for the function itself internally, the azure function app was not aware of this change in route, so it kept trying to serve the request at /api. removing this line fixed the issue. I believe that the likely solution in the end if we want to change the route suffix is to update both host.json and the value in Startup.cs, but that's another issue for another SO ticket (hopefully not)