Alpinebot not working

[fpittelo]

The web app is deployed, as the function and openai, but currently the chat is not working: chat are not sent receive by OpenAI. Chat API not reacheable

https://dev-alpinebot-as.azurewebsites.net/api/chat --> Error 404 (nginx/1.28.0)

Website: dev-alpinebot-func.azurewebsites.net
Azure function app: dev-alpinebot-func.azurewebsites.net > When connected it says "Your function app is running"

OpenAI dev-alpinebot-ai-3775 endpoint: https://switzerlandnorth.api.cognitive.microsoft.com/

[fpittelo]

I have identified the root cause: the REACT_APP_FUNCTION_APP_URL environment variable is missing during the frontend build step in the main deploy.yaml workflow. This causes the React app to be built without the backend URL, resulting in 404 errors as it tries to call API endpoints relative to itself.

Plan:

1. Update .github/workflows/deploy.yaml to inject the REACT_APP_FUNCTION_APP_URL environment variable during the "Build Frontend Application" step.
2. Commit and push the change.
3. Verify the fix by letting the pipeline deploy and testing the chat interface.

[fpittelo]

The fix for REACT_APP_FUNCTION_APP_URL was applied, confirming the frontend is now targeting the correct URL: https://dev-alpinebot-func.azurewebsites.net/api/chat.

However, the request still fails with a 404 Not Found. This suggests the Backend Function is either:

1. Not running/failed to start.
2. The chat function is not successfully registered.
3. There is a route prefix mismatch (default is /api).

Debugging Plan:

1. Added a simple /api/health endpoint to function_app.py to test basic connectivity and app status.
2. Verifying host.json configuration.
3. If /api/health works but chat fails, the issue is likely in the chat function's initialization (e.g., missing dependencies or immediate crash on load).

[fpittelo]

Debugging Update: Lazy Import Strategy

Context

The /api/health endpoint is working (returns 200 OK), meaning the Function App is running. However, /api/chat returns 404. This strongly suggests the chat function is failing to index/register during the worker startup process.

In Azure Functions Python V2, if a function implementation has top-level imports that fail (e.g., missing environment variables causing a crash, or missing dependencies), the worker might silently skip registering that specific function, resulting in a 404 for that route while the app itself remains "healthy".

Fix Implemented

I have refactored backend/function_app.py to move the openai imports and initialization inside the chat function scope.

Changes:

• Removed top-level from openai import AzureOpenAI.
• Moved client initialization inside the def chat(...) block.

Expected Outcome:

1. The app should start successfully.
2. The chat function should definitely register.
3. If there is a configuration/dependency issue, calling /api/chat will now return a 500 Internal Server Error (with a helpful error message) instead of a 404 Not Found.

Verification Steps

1. Deploy: Commit and push changes to backend/function_app.py.
2. Test: Call /api/chat from the frontend.
   • Success: Chat works.
   • Failure (500): We will see the specific error in the response body.
   • Failure (404): Indicates a deeper platform or host.json issue (unlikely given health works).

[fpittelo]

Debugging Update: Configuration Hardening

Context

Despite the "Lazy Import" fix, the 404 error persisted for /api/chat (and initially /api/health, though that seemed to resolve intermittently). The Azure Portal showed the functions as "Enabled", but the runtime was effectively unreachable.

Crucially, the Azure Portal displayed a warning that "Always On" was not enabled. For an S1 Dedicated App Service Plan, "Always On" is critical. Without it, the function host can go cold, unload, or fail to wake up properly for requests, leading to 404s.

Fix Implemented

I have applied the following hardening measures to ensure a stable, persistent runtime:

1. Enable "Always On": Updated infra/modules/function_app/main.tf to set always_on = true. This ensures the execution host stays loaded.
2. Downgrade to Python 3.11: Updated infra/modules/function_app/main.tf and .github/workflows/deploy.yaml to use Python 3.11. This is a stability measure to rule out any edge-case issues with the newer Python 3.12 runtime on Azure Linux Functions.

Verification Steps

1. Deploy: Commit and push changes. This will fail the Terraform check (drift) and then apply the new configuration (Always On), followed by a code deployment.
2. Stabilize: Allow ~1-2 minutes after deployment for the new "Always On" worker to initialize.
3. Test:
   • /api/health: Should return 200 OK {"status": "healthy"}.
   • /api/chat: Should return 200 OK (or 500 if there's an app logic error, but NOT 404).

[fpittelo]

Debugging Update: Explicit Runtime Configuration

Context

The "Always On" fix resolved the portal warning, but the 404 errors persist (even for the health check). This confirms the Azure Functions Runtime (WebJobs SDK) is failing to initialize correctly on the host, likely due to missing binding configurations.

Root Cause Analysis

For Linux Function Apps (especially on Dedicated plans), Terraform's storage_account_name shortcut often fails to correctly inject the critical AzureWebJobsStorage connection string into the App Settings. Without this setting:

1. The runtime cannot create/access the azure-webjobs-hosts container.
2. Triggers cannot participate in leader election or checkpointing.
3. The host runs (TCP 80 open), but the function runtime is a "zombie" (404 on all routes).

Fix Implemented

I have updated infra/modules/function_app/main.tf to explicitly inject the necessary app settings:

"AzureWebJobsStorage"         = azurerm_storage_account.function_storage.primary_connection_string
"FUNCTIONS_EXTENSION_VERSION" = "~4"

Verification Steps

1. Deploy: Commit and push. Terraform will update the Function App settings.
2. Verify: Call /api/health. It should now return 200 OK.
3. Chat: Call /api/chat. It should return 200 OK.

[fpittelo]

Debugging Update: Code Restoration

Incident Report

The previous "functions not appearing" issue was caused by an accidental code deletion during the refactoring process. The health endpoint code was inadvertently removed from backend/function_app.py, which explains why /api/health returned 404 and why the functions list might have appeared largely empty or broken if the file had parsing issues.

Fix Implemented

I have restored the health function in backend/function_app.py.

The file now correctly contains:

1. /api/health: Simple GET endpoint (Restored).
2. /api/chat: POST endpoint with lazy imports (Preserved).

Verification Steps

1. Deploy: Commit and push the fix to backend/function_app.py.
2. Verify:
   • Wait for deployment.
   • Check /api/health -> Expect 200 OK.
   • Check /api/chat -> Expect 200 OK (or appropriate error, but not 404).