Deploying Web App from Open AI results in 503 Application Error when accessing webapp.

[timpackwoodUOB]

Describe the bug
When attempting to deploy the web app from Open AI studio, I receive a successful deployment message but the web app that is provisioned returns a generic 503 Application Error.

To Reproduce
Steps to reproduce the behavior:

1. Deploy the web app from the Open AI studio chat playground.
2. Select the settings to deploy the web app in UK south
3. Visit the provisioned web app URL
4. Web app url results in 503 error

Expected behavior
That the web app would launch the chat application

Screenshots

Configuration: Please provide the following

• Azure OpenAI model name and version - GPT 4-0125-Preview
• Is chat history enabled? - Yes
• Are you using data? - No

Additional context

• In the web app I can see that the output.tar.gz remains compressed
• The logs display the following error - ERROR - Container name for site name has exited, failing site start
• I believe the issue is related to container being unable to start.

[jegberin]

same issue for me.
Attempted with and without "chat history enabled" and issue remains the same

[torronen]

EDIT: It did not help to skip the last 2 commits and retry.

Same here. I tried with different models, different datacenters, differenct machines etc. until realizing to look here. May I suggest there would be a "stable" branch in addition main? Then we could just pull from that branch without the latest updates, or alternatively a "develop" branch for latest changes? I am just trying to get from another branch.

The intent is probably to keep main as stable, but things can still happen so a more rarely updated branch would be nice.

I think it's the latest push, it's failing in checks also

I hope it's this, I will make fork from the earlier commit and see

[John-Vance]

I am also seeing this issue, and have tried deploying in multiple regions. Three chatbots that were intended to be upgraded to the 4o model are now completely inaccessible, with the same errors as previous comments.

[KBerry11]

I also have been having this issue all day.

[abhahn]

Hi everyone, sorry for the recent breakage. I've just recently merged a change to fix the issue introduced in one of the recent commits. In addition, I've added an improvement to our CI process to ensure that the docker image builds successfully as a prerequisite for merging PRs, so hopefully similar issues won't occur in the future.

I've just confirmed that syncing the most recent change to one of my existing broken apps has fixed the issue. I'm going to close this issue for now, but if you still observe a problem please feel free to reopen and we'll investigate.

[jegberin]

@abhahn , Issue remains the same for me, no fix... :(

[timpackwoodUOB]

Same for me, the original issue still persists for me. I'm deploying to UK south. GPT 4.

Container still failing to start.

[INFO] Reason: Worker failed to boot./home/LogFiles/2024_05_24_lw1ldlwk00009O_docker.log

[torronen]

+1

[oxch]

Same here - issue still persists - US East 2 app service deployment (B3 SKU) using GPT-4o model in US East 2 (same region as app service), no AI Search or own data options - basic chat.

[John-Vance]

The fix worked for me, I deployed three in East US today with AI/vector search on blob data using gpt-4-32k, zero issues.

[abhahn]

For those who are still experiencing an issue, can you add a comment with the application stack trace? If the worker is failing to boot, there may be a problem with the application during startup. There were a few refactoring changes to settings in another recent commit, which is the main thing I'd like to check for at the moment.

[abhahn]

Quick update: after another round of testing, I have discovered a few issues related to the DATASOURCE_TYPE variable and the way it was intended to be used in the settings refactoring PR.

I decided to make DATASOURCE_TYPE required in an effort to make it easy to switch between different datasource types, rather than relying on resolution of multiple variables to determine which datasource configuration is active in the environment. However, due to my failure to update the docs, this has caused an issue for some users who have deployed the app outside of the Azure OpenAI Studio, where the variable may not have been present before. In addition to this, users who are deploying from the Azure OpenAI Studio who are not actually using a datasource configuration at all would have hit a different issue, caused by the fact that the studio deployment template uses AzureCognitiveSearch by default, even if no other configs were set.

I have a change in #881 which should solve the issue of the application crashing on startup if the datasource is not configured properly -- a warning will be logged to indicate that a valid datasource configuration is not found if there is either 1) no matching configuration for the datasource type specified, or 2) no value of datasource type given at all. A quick fix while waiting for this to be merged would be to check the value in your app -- if using Azure Cognitive Search, be sure this value is set to AzureCognitiveSearch. If you're not intending to use a data source at all, be sure the value is empty.

[oxch]

Clearing DATASOURCE_TYPE variable set by template to AzureCognitiveSearch by default with no actual AI Search use resolved my issue of container not starting. All good now - thanks a lot @abhahn for looking into it quickly.

[torronen]

@abhahn Here are logs of web app deployed todays from Azure AI Studio. First with default DATASOURCE_TYPE, then after putting empty "" value on it (in env values trhough portal)

logs.zip

[torronen]

Deploy from Github's README.MD (deploy to Azure) works for East US. For Sweden it fail, because Classic App insights are not available