No audio output from deployed app

[nswitanek]

I've deployed the app using the dev container approach. I've not yet received an audio response from the app and am not sure where the app is breaking down. I'd be grateful for guidance in debugging my deployment.

[pamelafox]

Are you experiencing the error with the deployed endpoint or the development server?
Generally, I try to replicate an error with the development server, since then you can look in the terminal for the logs. Typically you'll see an error, like a 401 (authentication) or 429 (rate limits). If the error is only in production, then you'll need to query the container app logs for clues as to the issue. Also check the browser console for any JavaScript errors.

[beschmitt]

I have the same problem. I tried deploying the app with the whole azd up shebang and also tried running it on a local development server.
Both times the app starts and I can interact with it but I don't get an answer or an error-message

[pamelafox]

Do you see anything in the logs from the development server? Typically you'd see some thing from the web socket like 400 or 429.

[beschmitt]

The only output I get is in the console but nothing from web sockets. The last two GET-Calls in the console are to audio-processor-worklet.js and audio-playback-worklet.js so it looks like it's trying to give output but it can't.

[nswitanek]

Thanks for the tips, @pamelafox!
When running in the development server, I saw I was getting 401 errors.

I was following the docs and hoping for Entra-ID-based auth. At startup, it seems identity-based credentials are being successfully retrieved:

INFO:voicerag:Running in development mode, loading from .env file
INFO:voicerag:Using AzureDeveloperCliCredential with tenant_id 16b3c013-d300-468d-ac64-7eda0820b6d3
INFO:azure.identity._internal.decorators:AzureDeveloperCliCredential.get_token_info succeeded
INFO:azure.identity._internal.decorators:AzureDeveloperCliCredential.get_token succeeded

but given the 401 error, maybe I'm misreading those info lines.

I had to set the keys to the OpenAI and AI Search services in app/backend/.env, and change the value of the search semantic configuration in order to get the local development deployment running.

How does one modify a .env file that works when running locally to one that will work in the cloud with azd up? I expect you should be able to copy it into .azure/<my-azd-env-name>/.env with minimal changes. I think we just need to add the lines

AZURE_ENV_NAME=<my-azd-env-name>
AZURE_LOCATION=<my-azure-location>
AZURE_OPENAI_REUSE_EXISTING=true
AZURE_OPENAI_RESOURCE_GROUP=<my-openai-rg>
AZURE_SEARCH_REUSE_EXISTING=true
AZURE_SEARCH_SERVICE_RESOURCE_GROUP=<my-ai-search-rg>

plus maybe the following?

SERVICE_BACKEND_RESOURCE_EXISTS=false

It's hard to debug azd deployments because it seems that each change and retest costs about 30 minutes, 10 minutes for azd up and 20 for azd down to clear out all the resources so I can try again. Is there a faster way to debug azd deployments?

[nswitanek]

The endpoint deployed to Azure without complaint but the resulting app doesn't respond. I checked the container app logs and found the 401 error again, so it seems the api key isn't being set as an environment variable, and fallback to developer CLI credential or default credential is also failing.

I'm unclear how or whether main.bicep interacts with .azure/<my-azd-env-name>/.env to set environment variables. app/backend/app.py doesn't read them directly with load_dotenv() because the bicep file settings RUNNING_IN_PRODUCTION to true.

In the repo instructions it seems that environment variables need to be set manually with command line calls to azd env set. But on azd up, there is an INFO line that says

Loading azd env from /workspaces/aisearch-openai-rag-audio/.azure/<my-azd-env-name>/.env  

Is there a file-based way of setting these environment variables, either with the .env file (preferred for consistency with the development approach), or a shell script?

[pamelafox]

Here is the code that sets the environment variables for the ACA deployment:

aisearch-openai-rag-audio/infra/main.bicep

Line 201 in a05971e

AZURE_SEARCH_ENDPOINT: reuseExistingSearch

We typically don't use .env files in production, since often our local environment might differ from the production variables, and the Bicep is the preferred way to set them. You can then see the values in the Portal when you click on a container and view its environment variables.

If the auth is failing on the portal, that means the role access did not get set up correctly. Roles are set here:

aisearch-openai-rag-audio/infra/main.bicep

Line 351 in a05971e

// Roles for the backend to access other services

If you used azd up to create all the resources, then that role access should have gone through. You can open the OpenAI resource in the Portal, click the Access control tab, and view the roles there to confirm you see the app identity.