feat: Add Azure AI Foundry integration - LiteLLM spike#2011
feat: Add Azure AI Foundry integration - LiteLLM spike#2011ricofurtado wants to merge 2 commits into
Conversation
- Implemented Azure AI Foundry settings form for user configuration. - Integrated Azure AI Foundry model fetching and validation in the ingest settings section. - Added Azure AI Foundry logo and settings dialog to the model providers component. - Enhanced model helpers to support Azure AI Foundry as a model provider. - Created API endpoints for fetching Azure AI Foundry models and validating credentials. - Updated configuration management to include Azure AI Foundry settings. - Implemented health check and completion tests for Azure AI Foundry. - Added support for Azure AI Foundry in Langflow global variable synchronization. - Updated settings models to accommodate Azure AI Foundry API key and endpoint. - Enhanced provider health checks to include Azure AI Foundry.
github-actions
Bot
added
frontend
|
React Doctor found 3 new issues in 1 file · 3 warnings · score 84 / 100 (Needs work) · 0 fixed · vs 3 warnings
Reviewed by React Doctor for commit |
WalkthroughAdds Azure AI Foundry as a new LLM/embedding provider throughout the stack: backend config, model discovery endpoint, provider health/validation checks, settings API (get/update/remove), model registry routing, and frontend settings UI (dialog, form, queries, provider metadata, and section wiring). ChangesAzure AI Foundry Provider Support
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant AzureAIFoundrySettingsDialog
participant SettingsAPI as "/api/settings"
participant ModelsAPI as "/api/models/azure-ai-foundry"
participant AzureEndpoint
User->>AzureAIFoundrySettingsDialog: Enter endpoint/api key, click Save
AzureAIFoundrySettingsDialog->>ModelsAPI: Validate credentials
ModelsAPI->>AzureEndpoint: GET /models
AzureEndpoint-->>ModelsAPI: model list or error
ModelsAPI-->>AzureAIFoundrySettingsDialog: language/embedding models or error
AzureAIFoundrySettingsDialog->>SettingsAPI: POST settings update (endpoint, api key, deployments)
SettingsAPI-->>AzureAIFoundrySettingsDialog: success/error
AzureAIFoundrySettingsDialog-->>User: Update provider health, show toast, close dialog
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
enhancement
ricofurtado
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| "use client"; | ||
|
|
||
| import { useQueryClient } from "@tanstack/react-query"; | ||
| import { AnimatePresence, motion } from "motion/react"; |
There was a problem hiding this comment.
React Doctor · react-doctor/use-lazy-motion (warning)
Importing "motion" ships about 30 kb of extra code and slows page load. Use "m" with LazyMotion instead.
Fix → Use import { LazyMotion, m } from "framer-motion" with domAnimation features. Saves about 30kb.
| }); | ||
|
|
||
| useEffect(() => { | ||
| if (open) methods.reset(); |
There was a problem hiding this comment.
React Doctor · react-doctor/no-event-handler (warning)
Faking an event handler with a prop plus a useEffect costs an extra render & runs late.
Fix → Run the side effect in the event handler that triggers it, instead of watching its state from a useEffect. See https://react.dev/learn/you-might-not-need-an-effect#sharing-logic-between-event-handlers
|
|
||
| useEffect(() => { | ||
| if (open) methods.reset(); | ||
| }, [open]); |
There was a problem hiding this comment.
React Doctor · react-doctor/exhaustive-deps (warning)
useEffect can run with a stale methods.reset & show your users old data.
Fix → Don't blindly add missing dependencies. Read the hook callback first.
Bad:
useEffect(() => {
setCount(count + 1);
}, [count]);
Better:
useEffect(() => {
setCount((currentCount) => currentCount + 1);
}, []);
If the missing value is recreated every render, move it inside the hook or stabilize it before adding it to deps.
github-actions
Bot
added
enhancement
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| ) | ||
| except Exception as e: | ||
| return JSONResponse( | ||
| {"error": f"Could not connect to Azure AI Foundry endpoint: {str(e)}"}, |
github-actions
Bot
added
enhancement
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
frontend/app/api/queries/useGetModelsQuery.ts (1)
205-246: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffConsider extracting a shared model-fetch hook factory.
useGetAzureAIFoundryModelsQueryduplicates the fetch/useQuery boilerplate already present in the OpenAI/Anthropic/Ollama/IBM hooks in this file (same body-building, fetch, error-throwing, andstaleTime:0/gcTime:0/retry:falseconfig). Consolidating these into a single parameterized factory (provider id, endpoint path, param mapping) would reduce duplication and ease adding the next provider.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@frontend/app/api/queries/useGetModelsQuery.ts` around lines 205 - 246, The `useGetAzureAIFoundryModelsQuery` hook duplicates the same fetch-and-query setup used by the other provider hooks in `useGetModelsQuery.ts`; refactor this into a shared parameterized factory/helper that accepts the provider id, request path, and body mapping. Move the common `useQuery` configuration (`staleTime`, `gcTime`, `retry`) and the fetch/error handling into that reusable abstraction, then have `useGetAzureAIFoundryModelsQuery` call it with the Azure AI Foundry-specific endpoint and params.src/api/models.py (1)
208-278: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winCollapse the two identical
GETcalls into one request.The credential-validation call (Lines 212-220) and the model-list call (Lines 252-260) hit the same
endpoint.rstrip("/")with identical headers/timeout, doubling the round-trips. Fetch once, branch on the single response: return the 401/403 errors, then parse the body on 200.♻️ Sketch of consolidated fetch
language_models = [] embedding_models = [] try: async with httpx.AsyncClient() as client: response = await client.get( endpoint.rstrip("/"), headers={ "Authorization": f"Bearer {api_key}", "Content-Type": "application/json", }, timeout=10.0, ) if response.status_code == 401: return JSONResponse( {"error": "Invalid API key. Verify the key in Azure AI Foundry portal."}, status_code=400, ) if response.status_code == 403: return JSONResponse( {"error": "Access denied. Verify the API key has the required permissions."}, status_code=400, ) if response.status_code == 200: entries = response.json().get("data", []) for entry in entries: model_id = entry.get("id", "") if not model_id: continue item = {"value": model_id, "label": model_id} (embedding_models if "embed" in model_id.lower() else language_models).append(item) except httpx.TimeoutException: return JSONResponse( {"error": "Azure AI Foundry endpoint did not respond. Check the endpoint URL."}, status_code=400, )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/api/models.py` around lines 208 - 278, The Azure AI Foundry flow in the credential-check and model सूची retrieval path is making two identical GET requests to the same endpoint with the same headers and timeout. Consolidate this into a single httpx.AsyncClient request in the existing Azure AI Foundry validation logic, then branch on the one response: return the 401/403 JSONResponse errors, and on 200 parse the same body to populate language_models and embedding_models.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/app/settings/_helpers/model-helpers.tsx`:
- Around line 144-155: The azure_ai_foundry fallback entry in model-helpers is
using placeholder values as selectable model options, which can be persisted as
invalid deployment names. Update getFallbackModels so the language/embedding
hints are not treated as real choices, and make sure cloud-picker
ingest-settings only receives valid selectable options from
getFallbackModels().embedding. Use a disabled hint item or omit these
placeholders entirely and rely on empty-state messaging instead.
In `@src/api/provider_validation.py`:
- Around line 830-945: The Azure AI Foundry validation helpers are building the
wrong request URL shape by appending the deployment name to the endpoint. Update
`_test_azure_ai_foundry_completion` and `_test_azure_ai_foundry_embedding` to
use the documented models endpoint path and send the deployment/model identifier
in the JSON payload instead of as a URL segment. Keep the existing
response/error handling in these functions, but align the request construction
with the Azure AI Foundry contract so standard setups validate correctly.
- Around line 830-856: The Azure AI Foundry lightweight health check in
_test_azure_ai_foundry_lightweight_health currently treats any non-401/403
response as success, which lets unexpected 4xx/5xx responses pass validation.
Update this function to only accept the expected statuses (200 and 404) and
raise for every other status, mirroring the model-list health handler. Include
the response details (status and any useful body text) in the error path so
failures are explicit, and keep the existing timeout and logging behavior in
place.
---
Nitpick comments:
In `@frontend/app/api/queries/useGetModelsQuery.ts`:
- Around line 205-246: The `useGetAzureAIFoundryModelsQuery` hook duplicates the
same fetch-and-query setup used by the other provider hooks in
`useGetModelsQuery.ts`; refactor this into a shared parameterized factory/helper
that accepts the provider id, request path, and body mapping. Move the common
`useQuery` configuration (`staleTime`, `gcTime`, `retry`) and the fetch/error
handling into that reusable abstraction, then have
`useGetAzureAIFoundryModelsQuery` call it with the Azure AI Foundry-specific
endpoint and params.
In `@src/api/models.py`:
- Around line 208-278: The Azure AI Foundry flow in the credential-check and
model सूची retrieval path is making two identical GET requests to the same
endpoint with the same headers and timeout. Consolidate this into a single
httpx.AsyncClient request in the existing Azure AI Foundry validation logic,
then branch on the one response: return the 401/403 JSONResponse errors, and on
200 parse the same body to populate language_models and embedding_models.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 933eabc1-37c6-456a-84b6-0a9986e3f102
📒 Files selected for processing (22)
frontend/app/api/mutations/useUpdateSettingsMutation.tsfrontend/app/api/queries/useGetModelsQuery.tsfrontend/app/api/queries/useGetSettingsQuery.tsfrontend/app/settings/_components/agent-settings-section.tsxfrontend/app/settings/_components/azure-ai-foundry-settings-dialog.tsxfrontend/app/settings/_components/azure-ai-foundry-settings-form.tsxfrontend/app/settings/_components/ingest-settings-section.tsxfrontend/app/settings/_components/model-providers.tsxfrontend/app/settings/_helpers/model-helpers.tsxfrontend/components/icons/azure-ai-foundry-logo.tsxfrontend/components/provider-health-banner.tsxsrc/api/models.pysrc/api/provider_health.pysrc/api/provider_validation.pysrc/api/settings/endpoints.pysrc/api/settings/helpers.pysrc/api/settings/langflow_sync.pysrc/api/settings/models.pysrc/app/routes/internal.pysrc/config/config_manager.pysrc/config/settings.pysrc/services/models_service.py
| case "azure_ai_foundry": | ||
| return { | ||
| language: [ | ||
| { value: "my-gpt4o-deployment", label: "Enter your deployment name" }, | ||
| ], | ||
| embedding: [ | ||
| { | ||
| value: "my-embedding-deployment", | ||
| label: "Enter your deployment name", | ||
| }, | ||
| ], | ||
| }; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Placeholder fallback value can be silently selected as a real model.
Other providers' fallback lists use genuinely valid model identifiers, but here the value ("my-gpt4o-deployment" / "my-embedding-deployment") is just a placeholder while the label reads as an instruction ("Enter your deployment name"). Per getFallbackModels(...).embedding usage in frontend/components/cloud-picker/ingest-settings.tsx, this is rendered as a selectable dropdown option — a user could pick it, silently persisting an invalid deployment name that will fail downstream.
Consider rendering this as a disabled/non-selectable hint item, or omitting it from the selectable list entirely and relying on empty-state messaging instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@frontend/app/settings/_helpers/model-helpers.tsx` around lines 144 - 155, The
azure_ai_foundry fallback entry in model-helpers is using placeholder values as
selectable model options, which can be persisted as invalid deployment names.
Update getFallbackModels so the language/embedding hints are not treated as real
choices, and make sure cloud-picker ingest-settings only receives valid
selectable options from getFallbackModels().embedding. Use a disabled hint item
or omit these placeholders entirely and rely on empty-state messaging instead.
| async def _test_azure_ai_foundry_lightweight_health(api_key: str, endpoint: str) -> None: | ||
| """Test Azure AI Foundry credentials with a lightweight GET to the models endpoint.""" | ||
| if not api_key: | ||
| raise Exception("Azure AI Foundry API key is required.") | ||
| if not endpoint: | ||
| raise Exception("Azure AI Foundry endpoint URL is required.") | ||
|
|
||
| try: | ||
| async with httpx.AsyncClient() as client: | ||
| response = await client.get( | ||
| endpoint.rstrip("/"), | ||
| headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}, | ||
| timeout=10.0, | ||
| ) | ||
| if response.status_code == 401: | ||
| raise Exception("Invalid API key. Verify the key in Azure AI Foundry portal.") | ||
| if response.status_code == 403: | ||
| raise Exception("Access denied. Verify the API key has the required permissions.") | ||
| # 200 or 404 (empty catalog) both confirm the endpoint is reachable and the key is accepted. | ||
| logger.info("Azure AI Foundry lightweight health check passed") | ||
|
|
||
| except httpx.TimeoutException: | ||
| logger.error("Azure AI Foundry health check timed out") | ||
| raise Exception("Azure AI Foundry endpoint did not respond. Check the endpoint URL.") | ||
| except Exception as e: | ||
| logger.error(f"Azure AI Foundry health check failed: {str(e)}") | ||
| raise |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the function and nearby validation helpers.
rg -n "_test_azure_ai_foundry_lightweight_health|Azure AI Foundry|_extract_error_details" src/api/provider_validation.py src -S
# Show the relevant slice with line numbers.
sed -n '800,880p' src/api/provider_validation.py
# Search for any docs or comments describing expected status codes for Azure AI Foundry.
rg -n "Azure AI Foundry|Foundry.*404|404.*Foundry|401|403|health check" -S README.md docs src || trueRepository: langflow-ai/openrag
Length of output: 49426
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the implementation around the lightweight health check.
python3 - <<'PY'
from pathlib import Path
p = Path('src/api/provider_validation.py')
lines = p.read_text().splitlines()
for i in range(820, 870):
if i <= len(lines):
print(f"{i:4d}: {lines[i-1]}")
PYRepository: langflow-ai/openrag
Length of output: 2717
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for references to the Azure AI Foundry endpoint path and any status-handling logic.
rg -n "models endpoint|/models|empty catalog|404 \(empty catalog\)|Azure AI Foundry" src -SRepository: langflow-ai/openrag
Length of output: 8622
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Compare Azure AI Foundry handling with the other lightweight checks in this file.
python3 - <<'PY'
from pathlib import Path
p = Path('src/api/provider_validation.py')
lines = p.read_text().splitlines()
ranges = {
"openai": (250, 280),
"ollama": (620, 640),
"anthropic": (748, 770),
"azure": (830, 850),
}
for name, (a, b) in ranges.items():
print(f"\n### {name.upper()} {a}-{b}")
for i in range(a, b + 1):
if i <= len(lines):
print(f"{i:4d}: {lines[i-1]}")
PYRepository: langflow-ai/openrag
Length of output: 4948
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the Azure AI Foundry model-list validation route and its status handling.
python3 - <<'PY'
from pathlib import Path
p = Path('src/api/models.py')
lines = p.read_text().splitlines()
for i in range(200, 250):
if i <= len(lines):
print(f"{i:4d}: {lines[i-1]}")
PYRepository: langflow-ai/openrag
Length of output: 2546
🌐 Web query:
Azure AI Foundry GET /models expected status codes 404 empty catalog 401 403 resource endpoint
💡 Result:
In Azure AI Foundry, when making requests to the GET /models endpoint (or related model management APIs), specific HTTP status codes indicate common configuration or authorization issues. Standard status codes for these operations generally follow the REST API guidelines defined for the platform [1]. Key Status Code Meanings: - 200 OK: The request was successful and returned the requested data [2][3][4]. - 401 Unauthorized: This indicates an authentication failure [1][5]. Common causes include missing, expired, or invalid tokens/API keys [1][5]. Ensure the Entra ID token uses the correct scope (e.g., https://ai.azure.com/.default) and that API keys are valid [5]. - 403 Forbidden: This indicates a permission issue, typically occurring when the caller lacks the necessary Azure RBAC role assignments (such as Azure AI Foundry User) at the resource or project scope [1][5]. - 404 Not Found: This frequently occurs due to an incorrect URL, API version, or path [1][6]. If you receive a 404 while attempting to list models or access a specific model deployment, verify that: - The endpoint URL is copied exactly from the Azure AI Foundry portal [7][6]. - The deployment name matches exactly what is configured in your project (note that while routing may be case-insensitive, special punctuation or spaces can cause failures) [7]. - The API version used is supported [6]. - For Azure OpenAI-compatible routes, you are targeting the correct base URL and resource endpoint [7][6]. An empty catalog or "404 Not Found" result is most commonly linked to mismatches in the endpoint configuration, missing model deployments, or incorrect project targeting rather than an actual empty service state [7][8][6]. If you are using the older Azure AI Inference beta path, note that it has been deprecated; official documentation recommends migrating to OpenAI v1-compatible routes [9].
Citations:
- 1: https://ai.azure.com/api-reference/
- 2: https://learn.microsoft.com/en-us/rest/api/microsoft-foundry/azureopenai/models
- 3: https://learn.microsoft.com/en-us/rest/api/aifoundry/accountmanagement/accounts/list-models?view=rest-aifoundry-accountmanagement-2025-06-01
- 4: https://learn.microsoft.com/en-us/rest/api/azureopenai/models/list?view=rest-azureopenai-2024-10-21
- 5: https://learn.microsoft.com/en-us/azure/foundry/concepts/authentication-authorization-foundry
- 6: https://learn.microsoft.com/en-au/answers/questions/5852858/foundry-endpoint-not-working
- 7: https://learn.microsoft.com/en-us/azure/foundry-classic/foundry-models/faq
- 8: https://github.com/MicrosoftDocs/azure-ai-docs/blob/main/articles/foundry/foundry-models/includes/how-to-generate-responses-2.md
- 9: https://learn.microsoft.com/en-us/azure/foundry/how-to/integrate-with-other-apps
Fail closed on unexpected Azure AI Foundry statuses
This path currently marks any response other than 401/403 as healthy. That means 400/500s and unrelated error pages can pass validation. Mirror the model-list handler here: accept only the expected statuses (200/404) and raise on everything else with the response details.
🧰 Tools
🪛 GitHub Actions: autofix.ci / 0_ruff autofix.txt
[error] 853-853: Ruff (B904): Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling. Raise uses raise Exception("Azure AI Foundry endpoint did not respond. Check the endpoint URL.") without exception chaining.
🪛 GitHub Actions: autofix.ci / ruff autofix
[error] 853-853: Ruff B904: Within an except clause, raise exceptions with raise ... from err or raise ... from None.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/provider_validation.py` around lines 830 - 856, The Azure AI Foundry
lightweight health check in _test_azure_ai_foundry_lightweight_health currently
treats any non-401/403 response as success, which lets unexpected 4xx/5xx
responses pass validation. Update this function to only accept the expected
statuses (200 and 404) and raise for every other status, mirroring the
model-list health handler. Include the response details (status and any useful
body text) in the error path so failures are explicit, and keep the existing
timeout and logging behavior in place.
| async def _test_azure_ai_foundry_lightweight_health(api_key: str, endpoint: str) -> None: | ||
| """Test Azure AI Foundry credentials with a lightweight GET to the models endpoint.""" | ||
| if not api_key: | ||
| raise Exception("Azure AI Foundry API key is required.") | ||
| if not endpoint: | ||
| raise Exception("Azure AI Foundry endpoint URL is required.") | ||
|
|
||
| try: | ||
| async with httpx.AsyncClient() as client: | ||
| response = await client.get( | ||
| endpoint.rstrip("/"), | ||
| headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}, | ||
| timeout=10.0, | ||
| ) | ||
| if response.status_code == 401: | ||
| raise Exception("Invalid API key. Verify the key in Azure AI Foundry portal.") | ||
| if response.status_code == 403: | ||
| raise Exception("Access denied. Verify the API key has the required permissions.") | ||
| # 200 or 404 (empty catalog) both confirm the endpoint is reachable and the key is accepted. | ||
| logger.info("Azure AI Foundry lightweight health check passed") | ||
|
|
||
| except httpx.TimeoutException: | ||
| logger.error("Azure AI Foundry health check timed out") | ||
| raise Exception("Azure AI Foundry endpoint did not respond. Check the endpoint URL.") | ||
| except Exception as e: | ||
| logger.error(f"Azure AI Foundry health check failed: {str(e)}") | ||
| raise | ||
|
|
||
|
|
||
| async def _test_azure_ai_foundry_completion(api_key: str, llm_model: str, endpoint: str) -> None: | ||
| """Test Azure AI Foundry chat completion with the given deployment.""" | ||
| if not api_key: | ||
| raise Exception("Azure AI Foundry API key is required.") | ||
| if not endpoint: | ||
| raise Exception("Azure AI Foundry endpoint URL is required.") | ||
| if not llm_model: | ||
| raise Exception("A deployment name is required to test Azure AI Foundry completion.") | ||
|
|
||
| try: | ||
| completions_url = f"{endpoint.rstrip('/')}/{llm_model}/chat/completions" | ||
| payload = { | ||
| "messages": [{"role": "user", "content": "Hello"}], | ||
| "max_tokens": 10, | ||
| } | ||
| async with httpx.AsyncClient() as client: | ||
| response = await client.post( | ||
| completions_url, | ||
| headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}, | ||
| json=payload, | ||
| timeout=30.0, | ||
| ) | ||
| if response.status_code != 200: | ||
| error_details = _extract_error_details(response) | ||
| if response.status_code == 401: | ||
| raise Exception("Invalid API key. Verify the key in Azure AI Foundry portal.") | ||
| if response.status_code == 403: | ||
| raise Exception( | ||
| "Access denied. Verify the API key has the required permissions." | ||
| ) | ||
| if response.status_code == 404: | ||
| raise Exception( | ||
| f"Deployment '{llm_model}' not found. Check that the deployment name matches exactly what was created in Azure AI Foundry." | ||
| ) | ||
| if response.status_code == 429: | ||
| raise Exception("Azure AI Foundry rate limit exceeded.") | ||
| raise Exception(f"Azure AI Foundry API error: {error_details}") | ||
| logger.info("Azure AI Foundry completion test passed") | ||
|
|
||
| except httpx.TimeoutException: | ||
| logger.error("Azure AI Foundry completion test timed out") | ||
| raise Exception("Request timed out") | ||
| except Exception as e: | ||
| logger.error(f"Azure AI Foundry completion test failed: {str(e)}") | ||
| raise | ||
|
|
||
|
|
||
| async def _test_azure_ai_foundry_embedding( | ||
| api_key: str, embedding_model: str, endpoint: str | ||
| ) -> None: | ||
| """Test Azure AI Foundry embedding generation with the given deployment.""" | ||
| if not api_key: | ||
| raise Exception("Azure AI Foundry API key is required.") | ||
| if not endpoint: | ||
| raise Exception("Azure AI Foundry endpoint URL is required.") | ||
| if not embedding_model: | ||
| raise Exception("A deployment name is required to test Azure AI Foundry embeddings.") | ||
|
|
||
| try: | ||
| embeddings_url = f"{endpoint.rstrip('/')}/{embedding_model}/embeddings" | ||
| payload = {"input": ["test"]} | ||
| async with httpx.AsyncClient() as client: | ||
| response = await client.post( | ||
| embeddings_url, | ||
| headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}, | ||
| json=payload, | ||
| timeout=30.0, | ||
| ) | ||
| if response.status_code != 200: | ||
| error_details = _extract_error_details(response) | ||
| if response.status_code == 401: | ||
| raise Exception("Invalid API key. Verify the key in Azure AI Foundry portal.") | ||
| if response.status_code == 404: | ||
| raise Exception( | ||
| f"Embedding deployment '{embedding_model}' not found. Check that the deployment name matches exactly what was created in Azure AI Foundry." | ||
| ) | ||
| if response.status_code == 429: | ||
| raise Exception("Azure AI Foundry rate limit exceeded.") | ||
| raise Exception(f"Azure AI Foundry embedding error: {error_details}") | ||
| logger.info("Azure AI Foundry embedding test passed") | ||
|
|
||
| except httpx.TimeoutException: | ||
| logger.error("Azure AI Foundry embedding test timed out") | ||
| raise Exception("Request timed out") | ||
| except Exception as e: | ||
| logger.error(f"Azure AI Foundry embedding test failed: {str(e)}") | ||
| raise |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Azure AI Foundry chat completions REST API endpoint format api-version deployment model field 2026
💡 Result:
For Azure AI Foundry chat completions, the REST API uses the following primary endpoint format [1][2]: POST {endpoint}/openai/v1/chat/completions The {endpoint} can typically be formatted as either: - https://{resource-name}.openai.azure.com/openai/v1/ [3][2] - https://{resource-name}.services.ai.azure.com/openai/v1/ [3][2] Regarding the parameters: - api-version: With the v1 GA API, api-version is generally no longer required for standard chat completions [3]. If explicitly included, the v1 API supports values such as v1 and preview [1][4]. - model: The model field is a required string in the request body, specifying the deployment ID (e.g., gpt-4o, o3) being used for the generation [1][5][4]. For administrative tasks (such as listing, creating, or updating deployments), the management plane REST API uses a different endpoint structure under management.azure.com (e.g.,.../providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments/{deploymentName}?api-version=2025-06-01) [6][7][8]. In these management operations, the model property is specified within the request body as an object containing format, name, and version fields [6][7][8].
Citations:
- 1: https://learn.microsoft.com/en-us/rest/api/aifoundry/azureopenai/chat
- 2: https://learn.microsoft.com/en-us/azure/foundry/how-to/integrate-with-other-apps
- 3: https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/how-to/use-chat-completions
- 4: https://learn.microsoft.com/en-us/rest/api/microsoft-foundry/azureopenai/chat
- 5: https://learn.microsoft.com/en-us/azure/foundry/openai/latest
- 6: https://learn.microsoft.com/en-us/rest/api/aifoundry/accountmanagement/deployments/create-or-update?view=rest-aifoundry-accountmanagement-2025-06-01
- 7: https://learn.microsoft.com/en-us/rest/api/aifoundry/accountmanagement/deployments/list?view=rest-aifoundry-accountmanagement-2025-06-01
- 8: https://learn.microsoft.com/en-us/rest/api/aifoundry/accountmanagement/deployments/get?view=rest-aifoundry-accountmanagement-2025-06-01
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Map the relevant file and find surrounding Azure AI Foundry helpers/docs.
git ls-files | rg 'src/api/provider_validation.py|README|docs|azure|foundry|provider_validation'
echo '--- outline ---'
ast-grep outline src/api/provider_validation.py --view expanded | sed -n '1,220p'
echo '--- relevant mentions ---'
rg -n "Azure AI Foundry|openai/v1|chat/completions|embeddings|api-version|deployment|models/chat|openai/deployments" src/api/provider_validation.py README* docs* . -g '!**/node_modules/**' -g '!**/.git/**' || trueRepository: langflow-ai/openrag
Length of output: 50376
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the relevant section with line numbers if the file is manageable.
wc -l src/api/provider_validation.py
sed -n '780,980p' src/api/provider_validation.py | cat -nRepository: langflow-ai/openrag
Length of output: 8771
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect Azure AI Foundry settings/docs for the expected endpoint shape.
rg -n "Azure AI Foundry|openai/v1|services.ai.azure.com|openai.azure.com|api-version|deployment" \
frontend app docs README.md src tests \
-g '!**/node_modules/**' -g '!**/.git/**' | sed -n '1,240p'Repository: langflow-ai/openrag
Length of output: 23814
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the Azure AI Foundry settings dialog/form and any docs references.
for f in \
frontend/app/settings/_components/azure-ai-foundry-settings-dialog.tsx \
frontend/app/settings/_components/azure-ai-foundry-settings-form.tsx \
docs/docs/reference/configuration.mdx \
README.md
do
if [ -f "$f" ]; then
echo "### $f"
wc -l "$f"
sed -n '1,240p' "$f" | cat -n
echo
fi
doneRepository: langflow-ai/openrag
Length of output: 42817
🌐 Web query:
Azure AI Foundry REST API chat completions openai/v1 model field embeddings endpoint official documentation
💡 Result:
The Azure AI Foundry platform provides REST API endpoints for both chat completions and embeddings, following the standard OpenAI v1-compatible structure [1][2][3]. Chat Completions Endpoint The chat completions API is available at the following path [1][4]: POST {endpoint}/openai/v1/chat/completions Key details include: - Base URL: The {endpoint} corresponds to your Azure AI Foundry models API endpoint [1][4]. - API Version: You can specify an api-version query parameter, such as v1 or preview [1][4]. - Request Body: The API accepts standard OpenAI-style chat completion parameters, including messages (a list of conversation objects with roles) and the model field to specify the deployment name [1][4]. Embeddings Endpoint The embeddings API is available at the following path [2][3]: POST {endpoint}/openai/v1/embeddings Key details include: - Request Body: Requires an input field (string, array of strings, or array of integers/tokens) and a model field to specify the model name [2][3]. - Optional Parameters: You can include parameters such as dimensions (for specific models) and encoding_format (e.g., float or base64) to control the output [2][5][3]. - Limits: There are specific constraints on the input, such as a maximum of 8,192 tokens per input and a hard cap of 300,000 tokens summed across all inputs in a single request [2][6][3]. Documentation Note The Azure AI Foundry REST API documentation explicitly organizes these under the {endpoint}/openai/v1/ path, facilitating compatibility with OpenAI's SDKs and standard REST implementations [1][2][3]. Ensure you are referencing the current "Azure AI Foundry" documentation rather than legacy "classic" portal references, which may use different URL structures (e.g., containing /deployments/{deployment-id}/) [7][5][8][9].
Citations:
- 1: https://learn.microsoft.com/en-us/azure/foundry/openai/latest
- 2: https://learn.microsoft.com/en-us/rest/api/aifoundry/azureopenai/embeddings
- 3: https://learn.microsoft.com/en-us/rest/api/microsoft-foundry/azureopenai/embeddings
- 4: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/reference-preview-latest
- 5: https://learn.microsoft.com/en-us/azure/ai-foundry/model-inference/reference/reference-model-inference-embeddings
- 6: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/embeddings
- 7: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/references/on-your-data
- 8: https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/how-to/use-embeddings
- 9: https://learn.microsoft.com/en-us/azure/foundry-classic/openai/reference
🌐 Web query:
site:learn.microsoft.com Azure AI Foundry embeddings REST API openai/v1 embeddings model field official
💡 Result:
In the Azure AI Foundry OpenAI v1 embeddings REST API, the model field is a required string parameter that specifies the ID of the model to be used for the request [1][2][3]. Official documentation clarifies that this field must be set to your specific model deployment name [4][5]. Key details regarding this field: - Required: The model field is mandatory in the request body [1][3]. - Value: It should correspond to the name you assigned to your model deployment when you created it in your Azure AI Foundry resource [4][5]. - Usage: You can retrieve a list of your available models and their deployment names using the List Models API [1][3]. Note that Azure AI Foundry also provides a separate Azure AI Model Inference API (distinct from the OpenAI v1-style API), which also uses a model parameter to identify the specific model deployed on an endpoint [6][7]. However, for the openai/v1/embeddings route specifically, the model field remains the standard way to reference your deployment [1][2][3].
Citations:
- 1: https://learn.microsoft.com/en-us/rest/api/microsoft-foundry/azureopenai/embeddings
- 2: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/reference-preview-latest
- 3: https://learn.microsoft.com/en-us/rest/api/aifoundry/azureopenai/embeddings
- 4: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/embeddings
- 5: https://learn.microsoft.com/en-us/azure/foundry/openai/tutorials/embeddings
- 6: https://learn.microsoft.com/en-us/azure/ai-foundry/model-inference/reference/reference-model-inference-embeddings
- 7: https://learn.microsoft.com/en-us/rest/api/aifoundry/modelinference/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Narrow inspection of Azure AI Foundry UX/docs and any endpoint hints.
files=(
frontend/app/settings/_components/azure-ai-foundry-settings-dialog.tsx
frontend/app/settings/_components/azure-ai-foundry-settings-form.tsx
docs/docs/reference/configuration.mdx
README.md
)
for f in "${files[@]}"; do
if [ -f "$f" ]; then
echo "### $f"
ast-grep outline "$f" --view expanded | sed -n '1,220p' || true
echo "--- snippets ---"
rg -n "Azure AI Foundry|endpoint|api-version|openai/v1|services.ai.azure.com|openai.azure.com|deployment" "$f" || true
echo
fi
doneRepository: langflow-ai/openrag
Length of output: 4818
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the Azure AI Foundry config and model lookup code to infer the intended endpoint contract.
sed -n '110,150p' src/config/config_manager.py | cat -n
echo '---'
sed -n '170,320p' src/api/models.py | cat -n
echo '---'
sed -n '1,120p' src/services/models_service.py | cat -nRepository: langflow-ai/openrag
Length of output: 14390
Azure AI Foundry validation calls use the wrong request shape
_test_azure_ai_foundry_completion and _test_azure_ai_foundry_embedding append /{deployment}/... to an endpoint the app documents as .../models, which doesn’t match the Azure AI Foundry contract. These checks should use the documented request path and pass the deployment/model in the JSON body instead of as a raw URL segment, or standard Foundry setups will fail validation.
🧰 Tools
🪛 GitHub Actions: autofix.ci / 0_ruff autofix.txt
[error] 853-853: Ruff (B904): Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling. Raise uses raise Exception("Azure AI Foundry endpoint did not respond. Check the endpoint URL.") without exception chaining.
[error] 900-900: Ruff (B904): Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling. Raise uses raise Exception("Request timed out") without exception chaining.
[error] 942-942: Ruff (B904): Within an except clause, raise exceptions with raise ... from err or raise ... from None to distinguish them from errors in exception handling. Raise uses raise Exception("Request timed out") without exception chaining.
🪛 GitHub Actions: autofix.ci / ruff autofix
[error] 853-853: Ruff B904: Within an except clause, raise exceptions with raise ... from err or raise ... from None.
[error] 900-900: Ruff B904: Within an except clause, raise exceptions with raise ... from err or raise ... from None.
[error] 942-942: Ruff B904: Within an except clause, raise exceptions with raise ... from err or raise ... from None.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/provider_validation.py` around lines 830 - 945, The Azure AI Foundry
validation helpers are building the wrong request URL shape by appending the
deployment name to the endpoint. Update `_test_azure_ai_foundry_completion` and
`_test_azure_ai_foundry_embedding` to use the documented models endpoint path
and send the deployment/model identifier in the JSON payload instead of as a URL
segment. Keep the existing response/error handling in these functions, but align
the request construction with the Azure AI Foundry contract so standard setups
validate correctly.
2 participants
Summary by CodeRabbit
New Features
Bug Fixes