Automated sync from private repo (2026-05-21)#718
Closed
foundry-samples-repo-sync[bot] wants to merge 43 commits into
Closed
Automated sync from private repo (2026-05-21)#718foundry-samples-repo-sync[bot] wants to merge 43 commits into
foundry-samples-repo-sync[bot] wants to merge 43 commits into
Conversation
…l subsets (#181) Co-authored-by: Copilot <copilot@github.com>
Trivial HTML comment to validate end-to-end sync flow post-cutover. Will be removed in follow-up. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Removes the tire-kick HTML comment added in #200. End-to-end sync flow validated successfully. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Ankit Sinha <anksinha@microsoft.com> Co-authored-by: Copilot <copilot@github.com>
) Agent-Logs-Url: https://github.com/microsoft-foundry/foundry-samples-pr/sessions/ecdf5247-aaf0-4b01-a028-c2fbe7b2c8bc Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: ankitbko <3169316+ankitbko@users.noreply.github.com>
…d-agents (#233) * Move hosted-agents test-payload files to internal/tools/samples-hosted-agents Relocates per-sample test-payload.txt files out of the sample directories (so they're not part of the sample/Docker build context) into a dedicated internal tooling area mirrored by language/protocol/sample-name. Updates the hosted-agents-cloud-e2e workflow to read payloads from the new location and drops the now-unnecessary rm of test-payload.txt from the scaffolded service dir. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use sample dir basename, not matrix.name, for payload lookup matrix.name is the agent name from the manifest (e.g. human-in-the-loop-dotnet-invocations) which can differ from the sample directory name (human-in-the-loop). The payload folders are keyed by sample directory, so derive that from basename(matrix.path). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Antriksh Jain <antrikshjain@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Replace langchain-openai with langchain-azure-ai[opentelemetry] - Use AzureAIOpenAIApiChatModel with credential=DefaultAzureCredential() - Remove get_bearer_token_provider workaround - Upgrade pip in Dockerfiles
Ensures local runs read GITHUB_TOKEN from .env and updates the setup docs and runtime error message to point users at .env.example and azd env set. Co-authored-by: Lakshmi Ramakrishnan <lakshminaarayanan.ramakrishnan+microsoft@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add Python declarative-workflow hosted-agent sample
A new sibling sample under samples/python/hosted-agents/agent-framework/responses/06-declarative-workflow that demonstrates hosting an Agent Framework declarative (YAML-defined) workflow behind the Responses protocol.
The workflow.yaml uses an OnConversationStart trigger with SetVariable + SendActivity and templates {System.LastMessageText} into the response, requiring no model deployment or Foundry resources to run locally.
main.py loads the YAML via WorkflowFactory.create_workflow_from_yaml_path, wraps it with .as_agent(), and serves it via ResponsesHostServer. Requires the agent-framework-declarative fix that adds list[Message] support to declarative start executors.
Validated end-to-end locally: POST /responses with input 'Ben' returns 'Hello from a declarative workflow! You said: Ben'.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add multi-turn declarative customer-support hosted sample
Adds samples/python/hosted-agents/agent-framework/responses/07-declarative-customer-support: a realistic multi-turn declarative workflow that triages each user turn with a TriageAgent (structured output), then routes to a TechSupportAgent or BillingAgent specialist via InvokeAzureAgent (autoSend), or sends a direct reply for general/clarifying turns. Each user message re-runs the workflow with the full conversation history available via Conversation.messages, exercising the list[Message] trigger path end-to-end.
* Pin declarative samples to public feature/hosted-dwf branch
Until the agent-framework fix supporting Workflow.as_agent() with list[Message] inputs is published to PyPI, install agent-framework-core and agent-framework-declarative directly from the microsoft/agent-framework feature/hosted-dwf branch via git+https + subdirectory. This unblocks azd deployment of the declarative samples.
* Install git in declarative sample Dockerfiles for git+https reqs
The python:3.12-slim base image does not ship git, so pip's git+https install lines (used while we pin to feature/hosted-dwf) fail. Install git via apt-get during the build. Revert when requirements.txt switches back to PyPI.
* Add agent-framework-foundry to 07 sample requirements
main.py imports FoundryChatClient from agent_framework.foundry, which lives in the agent-framework-foundry package. Pulling agent-framework-core from the feature branch leaves the foundry subpackage missing; add it explicitly so the container can construct the chat client at startup.
* Set autoSend=false on triage agent in customer-support workflow
Default autoSend is true in the declarative engine, which caused the TriageAgent's raw structured-output JSON to be streamed back to the caller before (and instead of) the ConditionGroup branches firing. Disabling autoSend keeps the JSON out of the user-facing stream so SendActivity in the matched branch is the actual response, and the conversation history records natural-language assistant turns rather than JSON.
* Install .NET 10 runtime in declarative sample Dockerfiles
agent-framework-declarative uses the python powerfx package to evaluate '=...' expressions in workflow YAML (conditions, value expressions, responseObject paths). powerfx wraps a .NET assembly via pythonnet and requires the .NET 10 runtime to be available, otherwise expression evaluation raises 'PowerFx is not available (dotnet runtime not installed)' at the first ConditionGroup or =Expr lookup. Install .NET 10 via dot.net/v1/dotnet-install.sh during the image build so workflows that branch on agent output evaluate correctly.
* Install libicu for .NET runtime in declarative sample Dockerfiles
The .NET runtime fails at startup with 'Couldn't find a valid ICU package' on python:3.12-slim. Add libicu-dev to apt install so the .NET globalization stack (used by powerfx) initializes successfully.
* Pin declarative samples to alliscode/hosted-declarative for Enum fix
Switch the temporary git+https requirements from microsoft/agent-framework feature/hosted-dwf to alliscode/agent-framework hosted-declarative so the samples pick up the PowerFx Enum sanitization fix (str-subclass enums like MessageRole otherwise crash ConditionGroup eval). Will revert to feature/hosted-dwf or PyPI once the fix is upstream.
* Pin agent-framework-foundry-hosting to alliscode hosted-declarative
Pull foundry-hosting from the same branch as core/declarative so the workflow-agent path picks up the new fix that prepends Foundry storage history to input_messages. Without this fix, multi-turn declarative workflows lose context: the host only forwards the latest turn, and declarative state.initialize() wipes Conversation.messages even when a checkpoint is restored.
* Pin samples 06/07 to alliscode/agent-framework@baff7e33e
baff7e33e adds combined message+checkpoint_id support to Workflow.run,
which is what enables multi-turn declarative workflows to preserve
state across user turns when hosted via Foundry Hosted Agents. Pinning
to the SHA (instead of a moving branch ref) ensures Docker pip caches
correctly invalidate when the upstream branch advances.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Bump agent-framework SHA pin to e8dfcc90f for pivoted state-preserving Workflow.run
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Use plain-string SendActivity activity for cross-language parity
The dotnet declarative runtime only supports the plain-string form of
SendActivity 'activity:'; the object form ('activity: { text: ... }')
fails YAML deserialization because MessageActivityTemplate expects an
array there. Python's SendActivityExecutor accepts both forms, so use
the plain string in this sample to keep workflow.yaml byte-identical
with the corresponding dotnet sample.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Adding env vars to agent.yaml files for VS Code support
* Remove basic 06-declarative-workflow sample; renumber customer-support to 06
The basic 06 sample (greeting-only declarative workflow) added little beyond what the customer-support sample already demonstrates, so it has been removed. The multi-turn customer-support sample (formerly 07) is now 06-declarative-customer-support, and the parent README has been updated accordingly.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Updating readme.
* Address PR feedback: simplify requirements and remove obsolete git install
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add test-payload.txt with sample prompts
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add test-payload.txt files for C# agent-framework samples
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: alliscode <bentho@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Updates to READMEs of all major networking templates (bicep mainly, also some TF) Updates to READMEs of all major networking templates(bicep mainly, also some TF) * Automatic fixes --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
…ndard-agent-setup` (#257) * fix(15-private-network-standard-agent-setup): sanitize derived storage account name Storage account names must be 3-24 chars, lowercase, no hyphens. The current`var azureStorageName = toLower('${aiServices}${uniqueSuffix}storage')` derivationfails Azure validation when `aiServices` contains hyphens or pushes the resultover 24 chars. Both are common with enterprise naming conventions; the default`'aiservices'` (10 chars) hides the bug. Also adds a defensive 44-char cap on the derived Cosmos DB name. Closes #256 * Automatic fixes --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
…estructive subnets, vnetName precedence, DNS subscription normalization (#259) * fix(15-private-network-standard-agent-setup): harden BYO-VNet path (subnets, vnetName, DNS sub) Three small, related fixes to the BYO-VNet code path in the same sample: 1. Non-destructive subnet handling. New 'reuseExistingSubnets' parameter (default false). When true and useExistingVnet is set, the template skips the subnet PUT entirely and references the existing subnet IDs as-is. Avoids resetting privateEndpointNetworkPolicies, NSG and route table associations on platform-managed subnets. 2. 'vnetName' precedence and UX clarity. Default changed from 'agent-vnet-test' to '' and description rewritten so it is explicit that the parameter is ignored when existingVnetResourceId is set (the resource ID wins). Stops users from copying the misleading default alongside their resource ID. 3. 'dnsZonesSubscriptionId' normalization. Now accepts either a bare GUID (existing form) or the full '/subscriptions/<guid>' path; both resolve to the same effective subscription for cross-sub DNS zone references. Closes #258 * Automatic fixes * Automatic fixes --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
…l capabilityHost, BCP037 fix (#261) * feat(15-private-network-standard-agent-setup): BYO existing AI Foundry account + declarative account-level capabilityHost Three related changes that together make the sample work end-to-end against an existing (BYO) AI Foundry account in regulated/enterprise tenants: 1. ai-account-identity.bicep: new optional 'existingAccountResourceId' and 'skipModelDeployment' parameters. When existingAccountResourceId is set, the module references the existing AI Foundry (CognitiveServices/accounts kind=AIServices) account in its own RG/subscription instead of creating a new one. Outputs use ARM short-circuit ternary so only the chosen branch is evaluated. Default behavior (create new account) is unchanged. 2. add-account-capability-host.bicep (NEW): declarative module that creates the account-level capabilityHost. The current sample relies on the createCapHost.sh script being run manually before deployment. Without it, the project caphost creation fails with 'Foundry Account capabilityHost Not Found'. This module makes the flow fully declarative and idempotent regardless of whether the account is freshly created or pre-existing. 3. add-project-capability-host.bicep: documents the BCP037 suppression for capabilityHostKind. The Bicep type defs reject the property but the ARM API requires it; without it the capability host is created with no kind and downstream agents fail. createCapHost.sh is left in place for compatibility (consider removing in a follow-up). main.bicep wires the new module and adds a dependency on it from the project caphost so the bootstrap order is enforced declaratively. Closes #260 * Automatic fixes --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
…reuseExistingSubnets, and declarative caphost (#271) Updates the README to reflect the features added in #257, #259, and #261. Changes: - Parameters table: add reuseExistingSubnets (#259), existingAiFoundryAccountResourceId and skipModelDeployment (#261); update vnetName description and default to reflect the precedence-aware behavior introduced in #259. - BYO Resource Details: add new section 5 'Use an existing Microsoft Foundry account' documenting the BYOA flow; mention reuseExistingSubnets in the existing-VNet section; note that dnsZonesSubscriptionId now accepts both bare GUID and full ARM subscription paths (#259). - Pre-Deployment Notes: replace the stale 'deploy the project caphost bicep' instruction with a reference to the declarative account-level capability host added in #261. - Account Cleanup section: clarify that createCapHost.sh is now only required for the cleanup-then-recreate flow, not for first-time deployments. - Module Structure: add add-account-capability-host.bicep to the file tree (#261). - Limitations: add note about the BYO account + skipModelDeployment requirement. No code changes; documentation only.
* Updates to READMEs of all major networking templates (bicep mainly, also some TF) Updates to READMEs of all major networking templates(bicep mainly, also some TF) * Automatic fixes * More managed network updates more managed network updates * Automatic fixes --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
* Updates to READMEs of all major networking templates (bicep mainly, also some TF) Updates to READMEs of all major networking templates(bicep mainly, also some TF) * Automatic fixes * More managed network updates more managed network updates * Automatic fixes * small updates to cli.md file * Add CLI version to update to --------- Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
* feat: Add Voice Live integration samples for hosted agents * Remove unnecessary keyed session store * Move voice live integration sample to separate folder * Generalize the voice live client sample script * Update test payload --------- Co-authored-by: Jian Miao <jianm@microsoft.com> Co-authored-by: Brandon Miller <42854725+brandom-msft@users.noreply.github.com>
* feat: add openai-agents-sdk sample with Foundry Hosted agents * feat(hosted-agents): migrate openai-agents-sdk sample to responses * Optimized code, used valid endpoints Co-authored-by: Copilot <copilot@github.com> * refactor: move openai-agents-sdk sample from invocations to responses and update test-payload * Fixed the api errors Co-authored-by: Copilot <copilot@github.com> --------- Co-authored-by: Copilot <copilot@github.com>
…jects + Responses API (#280) Migrates the three C# hosted-agents bring-your-own samples off the legacy `Azure.AI.OpenAI` wrapper package (Chat Completions API) onto `Azure.AI.Projects` + `Azure.AI.Extensions.OpenAI` (Responses API), addressing ADO bug 5188484. Samples migrated: - responses/notetaking-agent - responses/background-agent - invocations/notetaking-agent Behavior preserved: - background-agent: real per-token streaming (CreateResponseStreamingAsync). - invocations/notetaking-agent: real per-token SSE streaming for the post-tool-call reply (matches the original CompleteChatStreamingAsync behavior). - Per-session JSONL note persistence (NoteStore.cs) unchanged. Hardening additions: - Function-call loop bounded by MaxToolRounds = 5 to prevent unbounded tool-call feedback loops. - Tool-argument JSON parsing in responses/notetaking-agent now uses TryGetProperty + try/catch JsonException, harmonizing with the invocations sibling. Verified end-to-end against a live Foundry project via `azd ai agent invoke --local`. Co-authored-by: Antriksh Jain <antrikshjain@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace Azure.AI.OpenAI (Chat Completions) with Azure.AI.Projects + Azure.AI.Extensions.OpenAI (Responses API) in samples/csharp/toolbox/maf/ToolboxMafAgent. - csproj: swap Azure.AI.OpenAI 2.1.0 for Azure.AI.Projects 2.0.0 + Azure.AI.Extensions.OpenAI 2.0.0 - Program.cs: AzureOpenAIClient/ChatClient -> AIProjectClient.ProjectOpenAIClient.GetProjectResponsesClientForModel - Convert tool-call loop to FunctionCallResponseItem + ResponseItem.CreateFunctionCallOutputItem - McpToolDefinition: emit OpenAI.Responses.FunctionTool via ResponseTool.CreateFunctionTool - Hoist tool-round limit (5) to a named MaxToolRounds constant; plumb CancellationToken through HTTP - README: align references with the new SDK surface Build: clean (warnings limited to pre-existing OpenTelemetry transitive CVE notices). Co-authored-by: Antriksh Jain <antrikshjain@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: add BYOK Foundry support for copilot invocations sample * fix: Simplify foundry openai endpoint derivation * fix: use project-level endpoint for model inference * fix: restore changes on invoke_handler * fix: revert unexpected changes --------- Co-authored-by: Copilot <copilot@github.com> Co-authored-by: Ankit Sinha <ankitbko@gmail.com>
* Add Agent Framework skills hosted agent sample Adds a Responses protocol hosted-agent sample that demonstrates native Agent Framework file-based skills with a script-backed travel guide PDF generator. Also adds the cloud E2E test payload that invokes the travel-guide skill. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use HOME-relative paths for generated skill outputs Removes the unsupported sandbox URI convention and returns Foundry's HOME-based output path from the travel guide skill. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add model env var to skills sample agent yaml Adds AZURE_AI_MODEL_DEPLOYMENT_NAME to agent.yaml so VS Code and other agent metadata consumers get the same environment variable declared in the manifest. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Lakshmi Ramakrishnan <lakshminaarayanan.ramakrishnan+microsoft@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat: add test payload for background agent AI impact analysis * fix: update skills provider initialization to use from_paths method --------- Co-authored-by: Ankit Sinha <anksinha@microsoft.com>
#253) * feat(samples): add initial Claude Agent SDK invocations sample for Microsoft Foundry * Fixed deployment issues and moved test payload to dedicated folder * Addressed comments related to code optimization and bug fix Co-authored-by: Copilot <copilot@github.com> * Removed redundant code * chore: add .ci-skip to exclude claude-agent-sdk from e2e pipeline discovery Agent-Logs-Url: https://github.com/microsoft-foundry/foundry-samples-pr/sessions/044ab706-2981-4388-bda4-f89498a8f15c Co-authored-by: ankitbko <3169316+ankitbko@users.noreply.github.com> * Fixed the streaming response --------- Co-authored-by: Copilot <copilot@github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: ankitbko <3169316+ankitbko@users.noreply.github.com>
* Add MAF Python files and observability samples * Resolve Toolbox connection * Update README * Update README * Update README * Update README
* Add voice live smoke test in cloud e2e pipeline * Little change - try to trigger E2E testing * Wait some time before voice live smoking * Correct the agent name * Make the timeout time longer --------- Co-authored-by: Jian Miao <jianm@microsoft.com>
* commit first draft. * working version. * removed sk. * cleanup and working version. * commit. * some cleanup. * commit working sample * cleanup --------- Co-authored-by: Brandon Miller <42854725+brandom-msft@users.noreply.github.com>
* feat(csharp/hosted-agents): add file-tools sample with bundled and session file knowledge sources Demonstrates two distinct file knowledge sources via security-scoped tool pairs: * Bundled files baked into the image at /app/resources/ via csproj Content Include. * Session files uploaded at runtime via "azd ai agent files upload" and read from HOME (/home/session). Each source is exposed via its own tool pair (List/Read), and each tool takes a fileName (no path-typed parameter). Implementation strips directory components, canonicalizes the path, and enforces StartsWith(root) so the model cannot escape its sandbox even via crafted input or indirect prompt injection. Validated live against tao-foundry-prj on gpt-4o: bundled prompt returns the verbatim figure, session prompt (after upload) returns the magic token, traversal attempt is refused. * docs(csharp/hosted-agents): list file-tools sample in parent README * Move test-payload to canonical e2e pipeline location The hosted-agents-cloud-e2e workflow only reads payloads from internal/tools/samples-hosted-agents/<lang>/<protocol>/<sample-dir>/test-payload.txt. The previous file at the sample root was never consumed by the pipeline.
…#284) * feat: add foundry-memory-rag .NET sample (agent-framework, responses) Personal-coach agent that uses FoundryMemoryProvider to remember user-private details across requests and sessions, hosted via the responses protocol. Memory store created on startup via EnsureMemoryStoreCreatedAsync (idempotent). Bicep + azure.yaml provision both chat (gpt-4.1-mini) and embedding (text-embedding-3-small) deployments via the langgraph-chat infra template. Per-user memory scoping is gated on a future hosting package release; sample uses a single shared scope today and references microsoft/agent-framework PR #5702 for the production pattern. * Address PR review feedback - Annotate every role-definition GUID across the infra/ Bicep tree as a public Azure built-in role, with Microsoft Learn links so reviewers can verify they are not credentials or tenant-specific identifiers. - Annotate the AppInsights dashboard ConfigurationId GUIDs as public Azure portal dashboard part identifiers. - Bump Microsoft.Agents.AI.Foundry.Hosting to 1.5.0-preview.260507.1 (latest preview drop) for parity with the framework main. * Drop sample-local bicep, rely on azd-ai-starter-basic template Per team guidance, hosted-agent samples should not ship their own infra/ or azure.yaml. The azd ai agent extension automatically pulls in the azd-ai-starter-basic template, which provisions the Foundry project, ACR, optional App Insights, and any model deployments declared in agent.manifest.yaml resources. Both gpt-4.1-mini and text-embedding-3-small are already declared in the manifest, so the starter handles them via AI_PROJECT_DEPLOYMENTS. Mirrors the canonical responses-protocol layout in samples/python/hosted-agents/bring-your-own/responses/langgraph-chat. Smoke-tested with azd ai agent init: manifest validates, both model entries preserved, starter template auto-cloned. * Add e2e test-payload for foundry-memory-rag Three-turn payload at the canonical pipeline location (internal/tools/samples-hosted-agents/csharp/responses/foundry-memory-rag/test-payload.txt). Two teach turns plus one recall turn exercise the FoundryMemoryProvider write/read flow end-to-end.
* Add event-grid-trigger BYO invocations sample Adds a hosted-agent sample that is event-driven from Azure Storage via Event Grid, with Azure API Management as the EG-to-Foundry bridge: Storage blob upload -> Event Grid -> APIM (system MI mints AAD token for https://ai.azure.com) -> POST {container, name} to the agent's Invocations URL -> agent reads the blob with its per-agent Entra identity, summarizes with a Foundry model, writes <name>.summary.json to a sibling 'summaries' container (loop-free). APIM owns the EG-specific concerns declaratively in policy (handshake, payload reshape, token attach) so the agent code has no EG-specific logic and no shared secrets. Also adds a row for the sample in samples/python/hosted-agents/README.md. * support basic query/message input schema * use absolute reference link for parent readme * tell how to get object id in README * tweak env syntax * tweak README * fix e2e ci * refactor: use UMI directly and remove APIM * refactor: use SAMI instead * tweak description in parent README
* .NET: add azure-search-rag hosted agent sample
RAG-backed hosted agent for Contoso Outdoors using TextSearchProvider over Azure.Search.Documents. Mirrors microsoft/agent-framework PR #5701 (Hosted-AzureSearchRag). Ships infra/ Bicep adapted from langgraph-chat for one-command 'azd provision'.
* Drop sample-local bicep, rely on azd-ai-starter-basic for Azure AI Search
Manifest now declares the Azure AI Search service via 'kind: tool, id: azure_ai_search', which 'azd ai agent init' translates into AI_PROJECT_DEPENDENT_RESOURCES so the starter template provisions the search service plus the project-scoped connection. agent.yaml derives AZURE_SEARCH_ENDPOINT from the starter's AZURE_AI_SEARCH_SERVICE_NAME output.
The starter's azure_ai_search.bicep currently requires a co-provisioned storage account, but 'azd ai agent init' does not auto-prompt for storage. README documents the manual azure.yaml edit until the starter is fixed.
* Add e2e test-payload for azure-search-rag
Three-turn payload at the canonical pipeline location. Each turn queries one of the three Contoso Outdoors documents seeded by the sample at startup (return policy, shipping guide, tent care).
* Use ${} for env var ref in agent.manifest.yaml
AZURE_AI_SEARCH_SERVICE_NAME is an azd-provisioned env var (not a manifest-declared parameter), so it must use ${} substitution rather than {{}} which is reserved for manifest parameters and resource names. Matches the pattern used in agent.yaml.
* Remove runtime index bootstrap, document one-time provisioning instead
The upstream Hosted-AzureSearchRag sample in microsoft/agent-framework and the Foundry.Hosting.IntegrationTests test container both assume the search index is pre-provisioned and only require Search Index Data Reader at runtime. This sample diverged by adding GetIndex/CreateIndex/UploadDocuments at startup, which forced the agent MI to also need Search Service Contributor and Search Index Data Contributor (a control-plane role + a data-write role).
Index provisioning is a one-time setup step and does not belong in the agent runtime. Strip BootstrapSearchIndexAsync from Program.cs and add a Provisioning the search index section to the README with a curl + az token script that creates the index and seeds the three Contoso Outdoors documents idempotently. Runtime RBAC drops back to Search Index Data Reader, matching the upstream sample and the IT scenario.
* Document RBAC auth mode requirement and Owner caveat for search service
Add two README sections that surface the gotchas hit during E2E setup: (1) the search service must have RBAC enabled (aadOrApiKey or AAD-only), with the az commands to verify and flip the mode; (2) Subscription Owner/Contributor/UAA do not grant data-plane access, the Search Index Data Contributor role must be granted explicitly even for owners.
#180) * refactor: update toolbox samples to AzureAIProjectToolbox pattern and add E2E CI workflow - Migrate langgraph toolbox samples (standalone and hosted-agents) to new AzureAIProjectToolbox abstraction from langchain-azure PR #525 - Remove manual MultiServerMCPClient wiring, token providers, and feature header boilerplate - Add langchain-azure-ai>=1.2.2 dependency to hosted-agents toolbox requirements - Update all toolbox README files to reference current repo manifest URLs instead of private-preview repo - Create .github/workflows/toolbox-cloud-e2e.yml for E2E testing with real Azure deployment validation - CI workflow includes: sample discovery, azd provision/deploy/invoke, response validation, and results reporting * fix(docs): use foundry-samples (public repo) instead of foundry-samples-pr in manifest URLs * fix(ci): relax E2E var validation; upgrade pip in hosted-agent Dockerfile - toolbox-cloud-e2e.yml: only hard-require AZURE_CLIENT_ID/TENANT_ID/SUBSCRIPTION_ID (matches existing hosted-agents-cloud-e2e). Soft-require AZURE_AI_PROJECT_ID, AZURE_AI_PROJECT_ENDPOINT, AZURE_AI_MODEL_DEPLOYMENT_NAME, TOOLBOX_ENDPOINT and skip the job cleanly with a warning when unset, so the workflow doesn't fail on a config gap that the repo owner hasn't filled in yet. - langgraph-toolbox Dockerfile: prepend `pip install --upgrade --ignore-installed pip`. The rpm-installed pip 24.2 in mcr.microsoft.com/azurelinux/base/python:3.12 cannot parse the `extra == "contentunderstanding"` marker on langchain-azure-ai >=1.2.3, which broke the image build during E2E. * ci(toolbox): hard-require credentials, add multi-toolbox matrix with per-endpoint queries * ci(toolbox): pass AZURE_CONTAINER_REGISTRY_ENDPOINT to azd deploy * ci(toolbox): run full toolbox matrix on PRs (no PR scoping) * fix(toolbox): pin langchain-azure-ai to 1.2.2 (avoid broken 1.2.3 metadata) * fix(toolbox): drop langchain-azure-ai [opentelemetry] extra (broken metadata) * fix(toolbox): upgrade pip in Dockerfile to fix PEP 508 marker parsing * fix(toolbox): pip upgrade with --ignore-installed to skip system pip * ci: re-trigger after granting AcrPull to proj1 MSI * fix(ci): set azd env before scaffold; tighten invoke failure detection * fix(ci): substitute placeholders in agent.yaml after scaffold (post-init) * ci: re-trigger after granting OpenAI User to agent identities * fix(ci): override hardcoded model in agent.yaml; grant role to dynamic agent identity * fix(ci): replace heredoc python with awk for env override * fix(ci): unique agent name per matrix job; reject hallucinated responses; save response artifact * chore: remove azd-scaffolded files from maf sample (regenerated by azd ai agent init) * ci(toolbox): one agent per sample (versions per toolbox) to avoid role-assignment churn Each sample now deploys to a single stable agent name (ci-toolbox-<sample>); each toolbox variant produces a new version of that same agent. A per-sample concurrency group serializes parallel deploys to the same agent. This collapses N (sample x toolbox x run) AgentIdentity SPs and their role assignments into 1 SP per sample, fixing RoleAssignmentLimitExceeded. * ci(toolbox): drop concurrency block (causes auto-cancel of queued jobs); skip 2 azd-samples GitHub Actions cancels jobs queued in the same concurrency group beyond max-pending=1, even with cancel-in-progress: false. With 6 toolbox jobs per sample sharing a group, 4 got auto-cancelled. Removing the block: parallel azd ai agent deploy to the same agent name just creates multiple versions (no role-assignment churn since the AgentIdentity SP is the same). Also added .ci-skip to azd-samples/{code-interpreter,web-search} which use azd's own connection-binding placeholder syntax incompatible with our toolbox endpoint substitution. * ci(toolbox): pin agent per (sample,toolbox) without run_number to avoid invoke race The previous one-agent-per-sample design caused parallel jobs deploying different toolbox versions to the same agent name to race: azd ai agent invoke targets the latest version, so e.g. csharp web-search invoke could hit the code-interpreter version (causing wrong-tool hallucinations). Reverting to per-combo names but dropping run_number so the AgentIdentity SP is stable across runs (~24 SPs total, well within RA budget — no churn). * ci: merge toolbox e2e into hosted-agents-cloud-e2e workflow - Discover toolbox samples alongside hosted-agents in single workflow - Cartesian-product toolbox samples over TOOLBOX_ENDPOINT entries - Conditional toolbox-only steps: agent.yaml name override, placeholder substitution, role grant - Hallucination detection scoped to toolbox samples - Delete standalone toolbox-cloud-e2e.yml * samples(toolbox): add github MCP + web_search to all 4 toolbox sample agent.yaml Aligns python/maf, python/langgraph, csharp/maf, python/azd with the reference shape (template + parameters + resources). Each agent.yaml now declares a github_pat parameter, a github-mcp-conn connection, and a toolbox with both web_search and the github MCP tool. * fix(toolbox): use flat agent.yaml format instead of nested template The nested template structure in agent.yaml silently fails during azd deployment because azd doesn't correctly parse it. The TOOLBOX_ENDPOINT environment variable is not properly substituted, causing agents to fail at runtime with 'TOOLBOX_ENDPOINT must be set' errors. Changes: - Remove nested template: wrapper from all toolbox agent.yaml files - Move metadata and description to manifest files - Keep agent.yaml as simple flat ContainerAgent spec - Ensures TOOLBOX_ENDPOINT is at root level for proper substitution - Fixes all failing E2E tests for toolbox samples Files changed: - samples/python/toolbox/maf/agent.yaml - samples/python/toolbox/langgraph/agent.yaml - samples/python/toolbox/azd/agent.yaml - samples/csharp/toolbox/maf/ToolboxMafAgent/agent.yaml * chore: remove accidentally committed development artifacts - github_managed_api_export.json: API export artifact, not part of the sample - samples/python/toolbox/demo_maf_web_search.py: local dev script, not a sample - samples/python/toolbox/demo_maf_outlook_mail.py: local dev script, not a sample These were untracked files picked up by 'git add -A' in the previous commit. * fix(toolbox): remove invalid trailing YAML lines from all agent.yaml files The replace_string_in_file tool left dangling lines from the old nested resources section (server_url, server_label, project_connection_id) after the TOOLBOX_ENDPOINT value in each file. These lines are at 8-space indentation inside a scalar value, making the YAML structurally invalid. The Foundry platform may interpret these as MCP connection directives, causing it to attempt a GitHub MCP connection for ALL toolbox tests, which interferes with aisearch, file-search, and github-mcp toolbox invocations. Files fixed: - samples/python/toolbox/maf/agent.yaml (server_url + project_connection_id) - samples/python/toolbox/langgraph/agent.yaml (project_connection_id) - samples/python/toolbox/azd/agent.yaml (project_connection_id) - samples/csharp/toolbox/maf/ToolboxMafAgent/agent.yaml (server_label + server_url + project_connection_id) * feat(e2e): add test payloads for toolbox samples (maf, langgraph, azd) * fix(toolbox-maf): add schema sanitization for GitHub MCP compatibility * fix(toolbox-maf): add error handling for GitHub MCP tool invocation * fix(toolbox-maf): add wrapper for safe MCPStreamableHTTPTool invocation with exception handling * Revert "fix(toolbox-maf): add wrapper for safe MCPStreamableHTTPTool invocation with exception handling" This reverts commit f8feb55b15825e2ad4d4c185c34f2d827563055d. * fix(toolbox-maf): sanitize GitHub MCP tool schemas via MCPStreamableHTTPTool subclass The GitHub MCP server returns tools with inputSchema type=object but no 'properties' field. The OpenAI Responses API rejects such schemas with HTTP 400 'Invalid HTTP request received.' Previous attempts targeted tool.args_schema (LangChain attribute) which does not exist on agent_framework.MCPStreamableHTTPTool. Root cause: MCPStreamableHTTPTool.load_tools() creates FunctionTool instances with input_model=tool.inputSchema (raw MCP dict), stored in FunctionTool._input_schema_cached. The fix subclasses MCPStreamableHTTPTool and overrides load_tools() to patch _input_schema_cached on each FunctionTool after super().load_tools(). * refactor(toolbox): consolidate azd-samples to README and add cross-references - Delete azd-samples/ directory (14 scenario subdirs consolidated into README.md with inline agent.manifest.yaml examples) - Align agent.yaml to runtime flat format (remove nested template wrapper) - Align agent.manifest.yaml to init-time config (GitHub MCP key-auth scenario) - Update .env.example to reflect AZURE_AI_MODEL_DEPLOYMENT_NAME, TOOLBOX_NAME env vars - Remove test payload files and unused PDF (per PR review) - Add cross-references in hosted-agents toolbox samples linking to foundational samples - Add hosted-agents link in toolbox README for deployment guidance * docs(toolbox): add cross-references between foundational and hosted-agents samples - Link hosted-agents toolbox samples to foundational samples in samples/python/toolbox/ - Link foundational toolbox README to hosted-agents deployment options - Clarify relationship between non-hosted (azd/maf/langgraph) and hosted-agents samples * Revert: remove cross-references to non-hosted samples in hosted-agents toolbox READMEs * docs(hosted-agents): add supported scenarios to all toolbox-related READMEs - Add 'Supported Scenarios' section to all 4 toolbox samples - Link to azd README with complete inline documentation of all 14 scenarios - Clarify available toolbox configurations for each deployment option * refactor(hosted-agents): create standalone toolbox scenarios documentation - Create SUPPORTED_TOOLBOX_SCENARIOS.md in hosted-agents folder with all 14 scenarios - Add references to scenarios file in all 4 toolbox-related READMEs - Remove cross-references to azd folder - keep scenarios isolated per deployment path - Fix agent.yaml to include missing required fields (protocols, metadata, description) * fix: add missing template block to agent.manifest.yaml - Add template section with proper structure (name, kind, protocols, environment_variables, resources) - Add displayName, description, metadata fields - Properly format parameters section with properties array - Ensure connection has category field - Remove duplicate server_url from toolbox tools * fix: restore scenario subdirectories for E2E test discovery - Restored all 14 toolbox scenario subdirectories under azd-samples/ - web-search, file-search, code-interpreter - mcp-keyauth, mcp-noauth, mcp-oauth-managed, mcp-oauth-custom - mcp-agent-identity, ai-search, a2a, bing-custom-search - openapi-keyauth, mcp-entra-passthrough, multi-tool - Each scenario has its own agent.manifest.yaml with proper configuration - Copied shared agent.yaml, main.py, Dockerfile, requirements.txt to each - E2E test discovery now finds each scenario as a separate test case - Fixes test matrix generation that was previously only testing mcp-keyauth * fix: add .ci-skip to scenario directories to prevent test explosion - Added .ci-skip files to all 14 azd-samples/* scenario directories - E2E discovery framework treats .ci-skip as 'external credentials required' - This prevents individual discovery and cartesian product multiplication - Scenario manifests remain available for manual/reference use - Maintains single test entry point at samples/python/toolbox/azd/ * fix: change default manifest to web-search (no credentials required) - Changed main agent.manifest.yaml from GitHub MCP to web-search - Web-search requires no external credentials, works for all test scenarios - Tests can now pass with whatever toolbox endpoint is provided - Scenario-specific manifests remain in azd-samples/ for user reference - Fixes test failures for web-search, code-interpreter, file-search, aisearch tests * fix: make manifest tool-agnostic for E2E testing - Removed specific toolbox type definition from manifest - Agent now works with any Foundry toolbox endpoint - TOOLBOX_ENDPOINT provided dynamically by test framework - Aligns with langgraph toolbox sample pattern - Fixes test failures when testing with different toolbox types - E2E tests can now test azd sample with web-search, code-interpreter, etc. * fix: add TOOLBOX_ENDPOINT to manifest environment variables - Added TOOLBOX_ENDPOINT to template.environment_variables - E2E test framework sets TOOLBOX_ENDPOINT for each toolbox type - Agent code checks TOOLBOX_ENDPOINT as fallback for toolbox connection - Ensures dynamic toolbox endpoint is passed through to container - Fixes invocation failures caused by missing toolbox endpoint * fix(toolbox-maf): add detailed logging for troubleshooting - Log when MCPStreamableHTTPTool is created - Log input and response length during agent execution - Log specific errors for timeout, cancellation, and consent failures - Helps diagnose why MAF tests fail on invocation These logs will be visible in 'azd ai agent monitor --type console' output * fix(toolbox-maf): remove user input from logs to pass CodeQL - Changed logger.info to log only input length, not content - User input may contain sensitive information - Prevents CodeQL security scanning warnings about logging user data - Keeps diagnostic information for troubleshooting (input char count) * fix: remove azd scenario subdirectories that trigger CodeQL alerts - Removed 14 scenario subdirectories under azd-samples/ - CodeQL flagged 30 high-severity 'Incomplete URL substring sanitization' alerts - Each scenario was a copy of the main sample with duplicate vulnerable code patterns - Keeping main azd/ sample is sufficient for E2E test matrix generation - Scenario references should use documentation in parent sample * fix: resolve CodeQL 'Incomplete URL substring sanitization' alerts - Added _has_consent_url() helper function to properly validate consent URLs using regex - Applied fix to azd/main.py, maf/main.py, and demo_maf_outlook_mail.py - Uses proper URL pattern matching instead of simple substring containment - Addresses all remaining CodeQL alerts for URL sanitization security CodeQL previously flagged: - 28 alerts from azd-samples/ subdirectories (removed in previous commit) - 2 alerts from maf/main.py URL validation - 2 alerts from demo_maf_outlook_mail.py URL validation All 32 alerts now resolved. * fix: resolve CodeQL alerts in langgraph/main.py - Added _has_consent_url() helper function for proper URL validation - Uses regex pattern matching instead of substring containment - Addresses remaining CodeQL 'Incomplete URL substring sanitization' alerts * chore: remove generated agent status/result artifacts from PR - Remove tracked files under logs_latest/ and logs_maf/ - Add .gitignore rules to prevent future accidental commits * chore: remove remaining generated logs_new artifacts - Untrack logs_new cloud E2E status/response/result files - Ignore logs_new to prevent future accidental commits * chore: remove demo MAF python files from PR * docs: remove broken KNOWN_ISSUES.md references * docs: revert unrelated hosted-agents README change * docs: restore hosted-agents langgraph toolbox README to main * chore: restore samples-mistral PDF to resolve merge conflict with main * fix(maf): cap oversized toolbox tool output for responses API * fix(maf): compact MCP schemas to avoid oversized responses requests * fix(maf): simplify MCP schemas for github-mcp and ms-learn * fix(maf): graceful fallback when Foundry rejects final render request * Add public langgraph toolbox user-identity hosted agent sample * fix(toolbox-azd): revert manifest to original configuration * Update agent.manifest.yaml * fix: update hosted-agents toolbox samples to use TOOLBOX_*_MCP_ENDPOINT pattern - Remove TOOLBOX_NAME environment variable from manifests - Use platform-injected TOOLBOX_{NAME}_MCP_ENDPOINT instead - Update 04-foundry-toolbox, bring-your-own-toolbox, langgraph-toolbox to use dynamic MCP endpoints - Addresses PR comment to standardize toolbox endpoint handling * revert: restore TOOLBOX_NAME pattern for hosted-agents toolbox samples - Restore TOOLBOX_NAME environment variables in manifests - Revert to using get_toolbox(TOOLBOX_NAME) pattern in main.py - Updates: 04-foundry-toolbox, bring-your-own-toolbox, langgraph-toolbox * fix: remove toolbox paths from hosted-agents E2E workflow Per PR comment, the hosted-agents-cloud-e2e.yml workflow should only test samples under hosted-agents/, not toolbox samples. Toolbox samples have their own separate E2E workflow (toolbox-cloud-e2e.yml). Addresses unresolved PR comment. * ci(toolbox): remove scaffolded postdeploy hook for renamed toolbox agents The scaffolded postdeploy hook looks up the agent by the original manifest name, but the workflow renames each toolbox matrix job to a unique AGENT_NAME, causing the hook's version lookup to 404 and fail the deploy. CI doesn't depend on the hook output, so dropping it for toolbox samples. * ci(toolbox): tolerate postdeploy hook failure with updated success pattern The postdeploy hook is configured inside azd-managed state (not hooks/), so it still fires after deploy succeeds. Match the actual azd success line ('<service>: Done [<time>]') in addition to the older format, and require the postdeploy-failed marker before tolerating non-zero exit. * Remove standalone toolbox sample folders (consolidated into hosted-agents) - Delete samples/python/toolbox/{azd,langgraph,maf,copilot-sdk}/ and samples/csharp/toolbox/{maf,crud-sample}/ (toolbox samples now live exclusively under samples/<lang>/hosted-agents/) - Drop the deleted paths from the hosted-agents-cloud-e2e discovery loops - Neutralize the is_toolbox glob (cartesian-product matrix is no longer used; hosted-agents toolbox samples manage their own toolbox setup) * Harden agent-framework foundry-toolbox sample against transient cold-start errors - main.py: retry get_toolbox() with exponential backoff so transient toolbox MCP readiness blips during cold start don't crash the container before /readiness can pass - workflow: retry 'azd ai agent invoke' on transient session_not_ready / 424 / readiness errors (up to 4 attempts with exponential backoff) * Restore is_toolbox detection for hosted-agents toolbox samples Match samples/<lang>/hosted-agents/*toolbox* so the cartesian-product matrix, TOOLBOX_PROJECT_ID, stable agent name, per-toolbox query, and hallucination check still apply to toolbox samples (which now live under hosted-agents). * ci(toolbox): substitute dynamically-named TOOLBOX_*_MCP_ENDPOINT placeholders azd derives the env-var name from the manifest's toolbox resource name (e.g. resource 'agent-tools' -> TOOLBOX_AGENT_TOOLS_MCP_ENDPOINT). The previous substitution loop only handled a fixed list, leaving these unsubstituted and failing the placeholder check. Add a generic regex pass and a matching override_env_var loop so any TOOLBOX_*_MCP_ENDPOINT is rewritten to the per-job toolbox URL. * ci: pin agent-framework<1.3 for foundry-toolbox sample (get_toolbox removed) FoundryChatClient.get_toolbox() was removed in agent-framework 1.3.0; this sample uses it. Pin to <1.3 until the sample is updated to the new API. * ci(hosted-agents): handle AAD role-propagation race on toolbox agent identity - Bump post-grant sleep from 60s to 120s (storage/history 401 has been observed up to ~2min after role grant on a brand-new agent SP). - Extend the invoke-step retry pattern to also retry on transient PermissionDenied / 'Principal does not have access' responses, with the same exponential backoff as the existing 424 readiness retry. * fix(toolbox samples): retry on transient cold-start / empty tool list When the toolbox MCP proxy returns 0 tools on cold-start, the model has no tools to call and answers from training data, which is flagged as 'hallucinated' by CI. Add a small retry loop (up to 5 attempts with exponential backoff up to 15s) to the three Python toolbox samples so the cached tool list is only populated once non-empty: - bring-your-own/responses/bring-your-own-toolbox/main.py - bring-your-own/responses/langgraph-toolbox/main.py - bring-your-own/responses/langgraph-toolbox-user-identity/main.py * ci: skip langgraph-toolbox-user-identity in CI The user-identity toolbox requires a real interactive OAuth/OBO token to enumerate tools. CI runs as a service principal so the toolbox returns 0 tools, causing the model to answer from training data (flagged as hallucination on the web-search query). * Revert "ci: skip langgraph-toolbox-user-identity in CI" This reverts commit feedc5105595b6b5746648f66b77e15fbea85f63. * Add GitHub PAT parameter and connection resource * fix(toolbox samples): TOOLBOX_ENDPOINT env var should override manifest TOOLBOX_NAME The three Python BYO toolbox samples constructed the MCP URL from TOOLBOX_NAME (set by the manifest) and only fell back to TOOLBOX_ENDPOINT when TOOLBOX_NAME was empty. CI's hosted-agents-cloud-e2e workflow expands each toolbox sample across multiple TOOLBOX_ENDPOINT URLs (aisearch, web-search, github-mcp, etc.) and expects the agent to use that endpoint. With the old precedence, the matrix value was silently ignored and every job hit the manifest-declared toolbox. Flip the precedence so an explicit TOOLBOX_ENDPOINT wins, and derive the toolbox name from the resolved URL. * ci(toolbox): append TOOLBOX_ENDPOINT to agent.yaml when missing azd ai agent init does not emit a TOOLBOX_ENDPOINT entry when the manifest only declares TOOLBOX_NAME, so override_env_var silently no-ops and the container falls back to the manifest-hardcoded toolbox URL. Detect missing entries and append them under environment_variables: so the matrix-injected TOOLBOX_ENDPOINT reaches the container. * ci(toolbox): do not append reserved FOUNDRY_*/AGENT_* env vars to agent.yaml The previous append behavior added FOUNDRY_PROJECT_ENDPOINT when missing, which the platform rejects with 'Environment variable FOUNDRY_PROJECT_ENDPOINT is reserved for platform use'. Skip the append branch for FOUNDRY_* and AGENT_* prefixes — they are platform-injected at runtime. * ci(e2e): POST /responses directly to print agent reply text azd ai agent invoke prints only header/footer metadata (Trace ID, Session, Conversation) and never emits the assistant's text. As a result every toolbox job was logging '✅ Agent responded successfully' regardless of whether the model actually produced content — masking real failures (e.g. agent_framework_openai 401 errors raised after response.created, which still return HTTP 200 to the client). For the responses protocol, bypass azd invoke and POST directly to the agent's /responses endpoint resolved from 'azd ai agent show'. Parse output[].content[].text via jq and echo it under '--- Agent response ---' markers, so existing error / hallucination grep checks operate on the real reply. The invocations protocol still uses azd invoke (opaque payload shape, validated by exit code). Each turn sends store:false to match samples' default_options. * ci(e2e): emit compact toolbox payload and catch python-dict error tokens Two bugs surfaced by improved logging: 1. invocations protocol: jq -n without -c emits pretty-printed multi-line JSON, but the invoke loop reads payload files line-by-line and treats each non-empty line as a separate turn. A single query object was being split into three garbage turns. Switch to jq -nc so toolbox queries stay on one line. 2. Error-detection grep only matched double-quoted JSON. The invocations protocol streams python-dict-style error tokens like Error calling model: ... { error : { message :...} } which slipped past the filter so the job logged a misleading success. Add alternation for single-quoted error key, the literal phrase Error calling model:, and invalid_request_error. * ci(hosted-agents): split matrix toolbox project per sample Route only the agent-framework foundry-toolbox-server-side samples (which resolve toolbox server-side via TOOLBOX_NAME) to the westus2 project where the MCP tool-name dot-prefix fix is live. All other samples remain on the proj1 toolbox project where per-agent runtime managed identities are pre-configured. * fix(toolbox): resolve MCP endpoint via azd-injected TOOLBOX_<NAME>_MCP_ENDPOINT Unify toolbox endpoint resolution across the four python hosted-agent toolbox samples (langgraph-toolbox, langgraph-toolbox-user-identity, bring-your-own-toolbox, invocations/toolbox). Priority order: 1. TOOLBOX_ENDPOINT (explicit full URL override) 2. TOOLBOX_<NAME>_MCP_ENDPOINT (azd auto-injects per toolbox in azure.yaml) 3. Construct from PROJECT_ENDPOINT + TOOLBOX_NAME (fallback) Also fixes NameError in langgraph-toolbox/main.py where _endpoint was referenced but not defined (only PROJECT_ENDPOINT existed). Adds TOOLBOX_NAME env var to the invocations/toolbox manifest so the new logic can derive the azd var name; removes broken {{TOOLBOX_ENDPOINT}} placeholder which azd init does not resolve. * ci(hosted-agents): route all toolbox-consuming samples to westus2 project BYO toolbox samples were failing on proj1 due to the MCP dot-prefix tool-name bug, and on westus2 with cross-project 401 because their runtime MIs lacked RBAC on the new account. Deploying them in westus2 directly auto-provisions Azure AI User on the parent account, sidestepping both the platform bug and the subscription role-assignment quota. * ci(hosted-agents): per-cell TOOLBOX_NAME + catch more hallucinations Two real bugs surfaced from inspecting agent responses on the prior 'all green' run: 1. agent-framework sample used a single global TOOLBOX_NAME=agent-tools for every matrix cell. The agent-tools toolbox in westus2 only contains web_search, so file-search/github-mcp/etc cells were silently falling back to the model's training data. Now derive TOOLBOX_NAME from matrix.toolbox_url so each cell points at its actual toolbox (e.g. github-mcp-key). 2. Hallucination detector missed several real failure phrases ('wasn't able to retrieve', 'temporary issue accessing', 'please upload', 'fictional company', 'likely because the repository is private'). Extended the pattern. Also uploaded employee_handbook.pdf to the westus2 file-search vector store which was empty. * ci(hosted-agents): restrict agent-framework foundry-toolbox samples to web-search only The two agent-framework foundry-toolbox samples (python 04-foundry-toolbox and csharp foundry-toolbox-server-side) ship an agent.manifest.yaml that hard-codes the inline 'agent-tools' toolbox with only the web_search tool. They cannot satisfy file-search / code-interpreter / github-mcp / etc. prompts regardless of which TOOLBOX_NAME we inject at deploy time, so previously these cells fell back to web_search and hallucinated 'Contoso is fictional' for the file-search prompt. Add a per-sample toolbox-label whitelist in emit_entries() so these two samples only enter the matrix paired with the web-search toolbox URL (their actual capability). All other toolbox-consuming samples (BYO) still fan out across all labels. * Revert: drop agent-framework foundry-toolbox web-search-only restriction The previous commit restricted the two agent-framework foundry-toolbox samples to the web-search matrix cell because their manifest hard-codes agent-tools = {web_search}. That was the wrong fix. The sample's agent.yaml substitutes \ into the container env, and main.py calls client.get_toolbox(TOOLBOX_NAME). With the per-cell TOOLBOX_NAME derivation already in place, each matrix cell resolves the pre-existing per-tool toolbox in the westus2 project (file-search, github-mcp-key, code-interpreter, etc.) — not the auto-provisioned agent-tools. So all tools should work; the previous file-search hallucination was caused by the empty vector store (now populated). * ci(hosted-agents): restrict agent-framework foundry-toolbox samples to web-search cell These two samples (python 04-foundry-toolbox, csharp foundry-toolbox-server-side) demonstrate server-side toolbox resolution: agent.manifest.yaml declares an inline 'agent-tools' toolbox with only web_search, azd auto-provisions it, and main.py calls client.get_toolbox(name). The sample's documented contract is web_search-only. Running these samples against file-search / github-mcp / etc. matrix cells tests something they never claimed to support and produced hallucinated answers ('Contoso is fictional', citations to developerscantina.com instead of the toolbox-attached vector store). Restrict their matrix expansion to the web-search cell only. The BYO toolbox samples still fan out across all 6 toolbox labels because they consume the MCP URL directly and are toolbox-agnostic. * ci(hosted-agents): override TOOLBOX_NAME in agent.yaml per matrix cell Root cause of agent-framework foundry-toolbox hallucination on non-web-search cells: 'azd ai agent init' regenerates agent.yaml from agent.manifest.yaml and HARDCODES 'value: agent-tools' in the TOOLBOX_NAME env entry (taking the manifest's literal value) rather than keeping the \ placeholder. So a plain 'azd env set TOOLBOX_NAME=...' is insufficient \u2014 the hardcoded value in agent.yaml wins at deploy time, and client.get_toolbox('agent-tools') only returns the auto-provisioned web_search-only toolbox regardless of which matrix cell we're targeting. Fix: in the 'Substitute placeholders' step, derive the toolbox name slug from the matrix toolbox URL (.../toolboxes/<slug>/mcp -> '<slug>') and call the existing override_env_var helper to rewrite the agent.yaml TOOLBOX_NAME value in place. This lets the agent-framework sample resolve file-search / github-mcp / etc. toolboxes correctly on each cell. Also revert the previous 'restrict to web-search cell' workaround \u2014 the sample now works across all toolbox labels. * ci(hosted-agents): retry invoke on 'agent version still being provisioned' (HTTP 400) Observed in aisearch toolbox cells: agent provisioning lags behind 'azd ai agent show' returning a stable endpoint, so the first invoke attempt gets HTTP 400 with message 'Agent version is still being provisioned'. Same shape as the existing 424/PermissionDenied retries \u2014 just add the new substring to the retry-eligible regex. * ci(hosted-agents): flip subscription + ACR for use_westus2 toolbox cells The use_westus2 toolbox matrix cells route the Foundry project to sub 921496dc (westus2) but the job was leaving AZURE_SUBSCRIPTION_ID and AZURE_CONTAINER_REGISTRY_ENDPOINT pinned to the ncus values (sub 47f1c914 / hostedagentsncusacr). azd's remote ACR build resolves the registry name against the current sub and falls back to local Docker when not found. Foundry's package service then cannot retrieve the build artifact and azd deploy fails with container publish failed: rpc error: code = Unknown desc = failed retrieving package result details Now the cell also flips AZURE_SUBSCRIPTION_ID (job env + azure/login + azd env) and points AZURE_CONTAINER_REGISTRY_ENDPOINT at the westus2 ACR connection backing the e2e-tests-westus2 project (crdyt765he4tmsy). * ci(hosted-agents): retry transient container-publish flakes The Foundry hosted-agent package service intermittently returns - container publish failed: rpc error: code = Unknown desc = failed retrieving package result details - ACR Tasks rawtext.log BlobNotFound (HEAD 404) from the ACR Tasks log-polling race. Both are timing flakes that clear on retry. Wrap 'azd deploy' in up to 3 attempts with linear backoff (30s, 60s) when the deploy log matches these patterns. Bump deploy timeout to 30m to cover the retries. * ci: probe langgraph-toolbox on ncus to test MCP dot-prefix fix * ci: route all toolbox samples to ncus (dot-prefix bug fixed) * ci: route toolbox samples back to westus2 (AcrPull granted; ncus MCP dot-bug not fully fixed) * samples(toolbox): switch model from gpt-4.1-mini to gpt-4.1 (mini quota exhausted in westus2) * ci: target role grant at the use_westus2 sub/scope so westus2 agent MIs get model access * ci(diag): pass --session to azd ai agent monitor so container logs surface on readiness 424 * ci: also grant Azure AI User at project scope so agent MI can call toolbox MCP (fix 401 from /toolboxes/.../mcp) * ci: fix role grant — 'Azure AI User' is not a real role; use 'Azure AI Developer' so toolbox MCP 401s clear * ci: also grant 'Cognitive Services User' (CognitiveServices/* data actions) so toolbox MCP accepts agent MI * ci: also grant Cognitive Services User at project scope for toolbox MCP Some MCP endpoints validate the caller's role at the project sub-resource and don't honor inherited assignments from the parent account. * ci: grant Foundry User role for toolbox MCP authorization Foundry's MCP gateway authorizes by specific role-name assignment at project scope (the Azure AI Developer description even says: 'For Foundry project access, use the Foundry User or Foundry Owner roles instead'). Cognitive Services User has the right CognitiveServices/* dataAction but is not recognized by the MCP authorizer. Grant Foundry User at both account and project scope. * ci: retry transient platform 500s and post-grant 401s; broaden session id extraction * Retry list now includes 'server_error' / 'internal server error' / '401 Unauthorized' to absorb transient platform failures and the residual MCP auth-cache propagation race after a fresh Foundry User role grant. * SID extraction now matches agent_session_id and session_id (in addition to 'session') so 'azd ai agent monitor' can pull container logs for responses-protocol failures. * ci(playwright): retry transient 424 session_not_ready and JSON-body server_error in smoke * 424 Failed Dependency surfaces as session_not_ready while a freshly deployed agent container is still warming up; treat it like 5xx and retry. * The Responses API can return HTTP 200 with a JSON body {error.code: server_error} indicating a transient platform fault; let retryTransient absorb it instead of failing the smoke run on the first occurrence. * fix(csharp): align foundry-toolbox-server-side manifest with working python sample * Drop container.type:auto subobject from code_interpreter (platform rejects with invalid_payload: 'param /tools/0/container — Value is null but should be string'). * Drop the orphan top-level mcp server_url entry — the platform expects all tools to be sourced from the toolbox resource named by TOOLBOX_NAME at runtime, not statically embedded in the manifest. * Match the python 04-foundry-toolbox manifest's tool descriptors (web_search + code_interpreter, both with name: ... ) which is the only known-good shape for the responses-protocol toolbox sample. * ci: fix monitor flag, false-positive error regex, hallucination/transient retry, playwright session timeout Five fixes pulled from PR #180 run analysis: * azd ai agent monitor flag is --session-id, not --session (broke last commit, no logs were captured for any responses-protocol failure since) * The error-pattern regex matched 'error: null' (always present in successful Responses API bodies) and falsely failed csharp github-mcp / ms-learn cells whose status:completed responses had output:[] but a literal error:null field. Tightened to only match string or object error values. * Added per-turn invoke retry on (a) HTTP 200 carrying a platform error (status:failed / server_error / invalid_payload) and (b) toolbox hallucination phrases. The model and platform are both non-deterministic; one extra attempt routinely clears them. * Bumped playwright RETRY_TIMEOUT_MS to 20 minutes for session_not_ready / 5xx — toolbox-enabled responses agents on a cold project have been observed to need >10 min to reach session readiness. * Excluded the csharp foundry-toolbox-server-side x code-interpreter combo with a loud ::warning::; this is a .NET Agent Framework SDK serialization bug (tools[].container = null) that cannot be fixed from this repo. TODO tagged for hosted-agents. * ci: fix exclusions jq quoting (single-quoted construct, pre-filter via separate pipe) Previous commit double-quoted the jq filter to interpolate $exclusions_jq, which broke jq parsing (Expected string key before ':'). Switch to pre-filtering the toolbox list via a separate jq invocation, then keep the original single-quoted construct filter unchanged. * ci: emit emit_entries diagnostic warnings to stderr (stdout is captured into matrix entries) The emit_entries function's stdout is consumed by 'done < <(emit_entries ...)' and appended to the entries array. Echoing '::warning::...' on stdout polluted entries with non-JSON, which then crashed the downstream 'jq -s {include: .}' slurp with 'Expected string key before :'. Redirect both warnings (csharp code-interpreter exclusion + empty-toolboxes skip) to stderr so they remain visible without breaking the matrix. * ci: retry transient HTTP/2 stream resets and connection drops on invoke Observed: azd ai agent invoke (invocations protocol) failed with 'error reading response stream: stream error: stream ID 3; CANCEL; received from peer'. This is a transient server-side stream reset and should be retried just like the other transient signals. * chore: remove accidentally committed .playwright-mcp/ browser session snapshots These 101 YAML snapshots were swept into commit dcfd16ec via 'git add -A' from a stale Playwright MCP debug session. They have no relation to the sample/CI changes on this branch. Also gitignore the directory so it cannot happen again. * chore: remove stray debug artifacts unrelated to toolbox samples / CI These five files were accidentally added to the branch via 'git add -A' during debugging and are unrelated to either the toolbox sample changes or the CI workflow fixes that are the actual subject of this PR. Removing keeps the diff against main scoped to samples/, the CI workflow, the playwright helper, and the .gitignore entry. * chore: remove accidentally-scaffolded azd infra under bring-your-own/responses These 17 files (azure.yaml + infra/ bicep + .gitignore) were generated locally by 'azd init --template ai-foundry-starter-basic' during debugging and swept into the branch via 'git add -A' in commit dcfd16ec. They are not referenced by the CI workflow nor by any of the actual leaf samples under bring-your-own/responses/ (each scaffolds its own azd project per matrix cell from agent.manifest.yaml). * fix(toolbox samples): unblock foundry-ext deployment for two failing samples 1) 04-foundry-toolbox: drop stale <1.3 pin on agent-framework. The comment claimed the sample relies on FoundryChatClient.get_toolbox(), but main.py uses MCPStreamableHTTPTool directly and never calls get_toolbox. The pin forced an incompatible combo with agent-framework-foundry-hosting (unpinned), crashing the container at startup so /readiness never returned 200 -> 424 session_not_ready. 2) bring-your-own-toolbox: downgrade azure-ai-agentserver-responses b5 -> b4 to match the working sister langgraph-toolbox sample. b5 surfaces a 500 server_error on every request in the foundry-ext deploy path (cloud-e2e azd deploy is unaffected). Drop the over-pinned core/projects/identity versions and let pip resolve compatible ones. * fix(toolbox samples): real foundry-ext fixes for 04-foundry-toolbox + bring-your-own-toolbox 04-foundry-toolbox: requirements use 'agent-framework[foundry]' instead of the bare package. main.py imports 'from agent_framework.foundry import FoundryChatClient'; in agent-framework 1.3+ that submodule is an optional extra (and 'agent-framework-foundry-hosting' only depends on agent-framework-core, not the [foundry] extra). Without the extra the import fails at startup, the container crashes, /readiness never returns 200, and the platform raises 424 session_not_ready on every invoke. bring-your-own-toolbox: harden response handler against transient platform errors. The previous handler awaited context.get_history() without a try/except — when foundry-ext sends store:true with a real conversation.id, any platform-store hiccup propagates as a 500 server_error. Cloud-e2e never hit this because it sends store:false. Now wraps get_history + the executor call in try/except + asyncio.wait_for, mirroring the defensive pattern in the working sister langgraph-toolbox sample. * fix(foundry-ext): unblock 04-foundry-toolbox readiness + flake-tolerant 412 04-foundry-toolbox: switch to sync main()/server.run() (matches the passing 03-mcp pattern). The async-with-Agent path eagerly entered the MCPStreamableHTTPTool context at startup, which performs a network MCP initialize + tools/list against the toolbox endpoint before the HTTP server is bound. On the foundry-ext deploy path the platform probes /readiness within ~90s of container start; with the MCP handshake still in flight, /readiness never returned 200 and the platform raised 424 session_not_ready on every invoke. Letting Agent enter the tool context lazily on first request keeps startup fast. agentApiSmoke.ts: add 412 to the retryable status list. The platform returns 412 precondition_failed when it observes a concurrent edit on the agent/session resource (a benign deploy+smoke race), as seen on langgraph-toolbox-user-identity. * ci(cloud-e2e): prune orphaned role assignments before granting agent SP roles Each azd deploy mints a fresh ephemeral AgentIdentityBlueprint SP and we grant up to 7 role assignments per SP across two scopes (account + toolbox project). Across many parallel matrix jobs and re-runs the per-scope role-assignment count fills with assignments whose principal SP has since been deleted (surface as principalType: Unknown / empty principalName). Azure surfaces this as RoleAssignmentLimitExceeded: No more role assignments can be created, and the in-container MCP call subsequently fails auth. Before granting the fresh role set, list assignments at both scopes and delete orphans whose roleDefinitionName is one of the four we manage (Cognitive Services OpenAI User, Cognitive Services User, Azure AI Developer, Foundry User). Uses jq to filter the az output. Errors are tolerated so we never block the deploy on cleanup. * ci(cloud-e2e): re-enable per-job agent cleanup; delete agent SP + role assignments Root cause of RoleAssignmentLimitExceeded: the Cleanup deployed agent step has been disabled (if: false # Temporarily disabled for manual testing) since before this branch, so every CI job leaks: (1) the deployed agent record in the Foundry project, (2) the AgentIdentityBlueprint SP that azd mints per deploy, and (3) the up-to-7 account-scope + up-to-3 project-scope role assignments granted to that SP. With ~30 parallel matrix jobs per run x multiple runs/day, the project-scope role-assignment quota (~200) fills within a day and subsequent grants fail. Re-enable the cleanup step (if: always so failures still drain) and broaden it to: capture the agent identity appIds via 'azd ai agent show' BEFORE deletion, DELETE the agent record, then for each captured SP delete role assignments at both managed scopes (account + project) and finally delete the SP itself (so any inherited or out-of-band assignments also become true Unknown-principal orphans that the existing cleanup_orphans helper can catch on subsequent runs). Endpoint and scope are derived per-matrix: toolbox samples use TOOLBOX_PROJECT_ID(_WESTUS2); plain samples use AZURE_AI_PROJECT_ID/ENDPOINT. Agent name uses the truncated AGENT_NAME env (matches what azd actually deployed), not raw matrix.name. * Defensively wrap context.get_history in 04-foundry-toolbox Workaround for an alpha bug in agent_framework_foundry_hosting==1.0.0a260514 where ResponsesHostServer._handle_inner_agent calls await context.get_history() unconditionally. When the platform sends store=true + a real conversation.id (foundry-extension deploy path), the history fetch can raise inside the SDK and bubbles up as platform server_error with no diagnostic. Subclass the host server and replace context.get_history with a safe wrapper that degrades to no prior history on error. * Skip Responses smoke for 04-foundry-toolbox; log error body The agent_framework_foundry_hosting alpha returns an opaque platform server_error for store=true + conversation.id requests against the foundry-extension deploy path. The 20-minute retry budget consistently exhausts. Cloud E2E (store=false) passes; deploy itself succeeds. Skip the Responses smoke for this one sample with a clear console.warn explaining why, until the upstream SDK ships a fix. Also log the full Responses API error body to the test artifact before throwing so future failures surface the platform's response (which the platform itself sanitizes). * ci: retrigger workflows after GitHub Actions infra outage Run 25906618376 (Cloud E2E) and 25906618401 (Foundry-ext) on commit ab9cd720 hit a transient GitHub Actions infrastructure issue: 11 cloud-e2e jobs got stuck in the queued state and never started, and the artifact upload step failed with HTML-error-page 5xx (FinalizeArtifact: Unexpected token '<'). All actual smoke tests that did run passed. Push empty commit to retrigger. --------- Co-authored-by: zhuoqunli <copilot@github.com>
…es with per-agent identity (#298) * Add 09-downstream-azure: hosted agent calling downstream Azure Storage with per-agent identity Adds a new Python sample under samples/python/hosted-agents/agent-framework/responses/09-downstream-azure that demonstrates the canonical "hosted agent -> downstream Azure service" pattern from the Foundry Hosted Agents concept doc: an Agent Framework agent hosted on the Responses protocol that reads and writes notes in Azure Blob Storage using its per-agent Microsoft Entra identity (resolved via DefaultAzureCredential inside the sandbox; the developer identity locally with `azd ai agent run`). The sample uses Azure Blob Storage as the example, but the pattern applies unchanged to any Azure service that authorizes data-plane calls via Entra ID (Cosmos DB, Service Bus, Event Hubs, etc.) - swap the SDK + role assignment and the rest is identical. Files: - README.md - explains the pattern, RBAC setup, local + deployed test instructions, and contrasts it with the Foundry-connection pattern in 08-connections-overview. - main.py - ResponsesHostServer agent registering save_note / list_notes / read_note / delete_note function tools that hit Blob Storage via DefaultAzureCredential. - agent.yaml - hosted agent manifest (Responses 1.0.0) with cpu/memory and AZURE_STORAGE_ACCOUNT_NAME / AZURE_STORAGE_CONTAINER_NAME / AZURE_AI_MODEL_DEPLOYMENT_NAME wired via azd ${VAR} substitution. - agent.manifest.yaml, Dockerfile, requirements.txt, .dockerignore, .env.example - standard hosted agent layout matching sibling samples. Verified end-to-end: - Local smoke test via `python main.py` (developer identity writes to the container). - Deployed-agent test via `azd init / provision / deploy` against an existing Foundry project, then `azd ai agent invoke`. The deployed agent's per-agent identity (not the user) wrote deploy-test.md to the target container, confirmed via `az storage blob list`. * simplify requirements.txt; use placeholder for model in agent yml * 09-downstream-azure: split tools into a package and add Service Bus alongside Storage Refactors the sample's tool surface and updates supporting metadata so it demonstrates the per-agent identity pattern across two Azure data-plane services that both use standard ARM RBAC: Blob Storage and Service Bus. Tool layout ----------- - Move the storage tools out of main.py into tools/storage.py and add tools/servicebus.py with send_message, peek_messages, and receive_message tools (azure-servicebus). tools/__init__.py exposes ALL_TOOLS so main.py just registers the aggregate list. - Generalize the storage tool names to storage_put_blob / get_blob / list_blobs / delete_blob (was save_note / list_notes / read_note / delete_note) so the sample is no longer "notes"-flavored. Sample wiring ------------- - main.py: rebuild instructions string around the two services and wire ALL_TOOLS into the FoundryChatClient + Agent + ResponsesHostServer. - agent.manifest.yaml + agent.yaml: rewrite description and tags for the two-service framing; add AZURE_SERVICEBUS_FQDN and AZURE_SERVICEBUS_QUEUE_NAME alongside the existing AZURE_STORAGE_* variables; keep AZURE_AI_MODEL_DEPLOYMENT_NAME wired via the AgentSchema {{...}} prompt against a kind: model resource. - requirements.txt: add azure-servicebus. - .env.example: add the Service Bus block; tidy formatting (drop the empty-quote placeholders) to match the template in the hosted-agent sample guidelines. README ------ Rewrite to follow the hosted-agent sample template and the parent README's style: - Drop the "Foundry VS Code extension" path; defer running and deploying instructions to the parent README and only document what's specific to this sample (extra Azure prerequisites, RBAC, sample env vars, sample-specific prompts). - Add a "Granting the agent data-plane access" section with bash + ps variants for both Storage and Service Bus role assignments, and call out that the role goes on the developer principal locally vs. the per-agent identity once deployed. - Use canonical env var names (FOUNDRY_PROJECT_ENDPOINT, AZURE_AI_MODEL_DEPLOYMENT_NAME, APPLICATIONINSIGHTS_CONNECTION_STRING) and consistent bash + PowerShell snippets for both env setup and azd ai agent invoke / curl examples. - Trim the troubleshooting section to the realistic failure modes (Storage AuthorizationPermissionMismatch, Service Bus Unauthorized, local credential errors). Validation ---------- Add sample.yaml at the standard Level 3 (Load) bar used by the other Python samples in the repo: build: pip install -r requirements.txt validate: python -m compileall -q . compileall is used instead of py_compile *.py because this sample has a tools/ subpackage that *.py would not recurse into. Verified end-to-end ------------------- azd deploy redeployed the agent (version 3) to agent-framework-agent-downstream-azure-responses on the existing Foundry project, and azd ai agent invoke exercised both the Storage and Service Bus tools successfully via the per-agent identity. * reduce number of tools * add entry points in root README * use absolute reference link for parent readme * tell how to get object id in README * tweak README * tweak env syntax * add test-payload.txt
* rename RBAC roles * Automatic fixes --------- Co-authored-by: Sheri Gilley <sheri.gilley@gmail.com> Co-authored-by: foundry-samples automation <foundry-samples@noreply.github.com>
This sample will now also be used in another article; the comment would be confusing there.
Updated template 19 with fixed code for bringing existing VNET Co-authored-by: Meera Kurup <meerakurup+microsoft@microsoft.com>
* Update model in quickstart-responses.sh * remove comments
…#338) The scheduled sync to microsoft-foundry/foundry-samples has been failing on the seed-marks-recovery safeguard because public main has a different version of this file than private last synced. Root cause: microsoft-foundry/foundry-samples/.github/workflows/run-setup.yml runs on every push to public main and regenerates azuredeploy.json with bicep-latest, then pushes directly to main as "Automatic fixes" (public commit 21fe221). Private's azuredeploy.json was generated with bicep 0.35.1; public's workflow rewrote it with bicep 0.43.8. No semantic logic change -- just _generator.version, recalculated templateHashes, and Microsoft.Resources/deployments apiVersion bumped from 2022-09-01 to 2025-04-01. This commit aligns private with public so the next sync run can succeed. The structural fix (disable public's run-setup.yml; make public a pure mirror) is tracked in ADO Bug 5293956: https://msdata.visualstudio.com/Vienna/_workitems/edit/5293956 This unblock work tracked in ADO Task 5294148: https://msdata.visualstudio.com/Vienna/_workitems/edit/5294148 Failed sync run that motivated this change: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/26147601924 Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Comment on lines
+10
to
+52
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Build payload and call Azure DevOps | ||
| env: | ||
| ADO_ORG: ${{ secrets.ADO_ORG }} | ||
| ADO_PROJECT: ${{ secrets.ADO_PROJECT }} | ||
| ADO_PAT: ${{ secrets.ADO_PAT }} | ||
| DRI_EMAIL: ${{ secrets.DRI_EMAIL }} | ||
| ADO_AREA_PATH: ${{ secrets.ADO_AREA_PATH }} | ||
| ADO_ITERATION_PATH: ${{ secrets.ADO_ITERATION_PATH }} | ||
| ADO_TAG: ${{ secrets.ADO_TAG }} | ||
| ISSUE_TITLE: ${{ github.event.issue.title }} | ||
| ISSUE_BODY: ${{ github.event.issue.body }} | ||
| ISSUE_URL: ${{ github.event.issue.html_url }} | ||
| run: | | ||
| DESCRIPTION="<div>${ISSUE_BODY//$'\n'/<br/>}<br/><br/><a href=\"$ISSUE_URL\">$ISSUE_URL</a></div>" | ||
|
|
||
| jq -n \ | ||
| --arg title "$ISSUE_TITLE" \ | ||
| --arg desc "$DESCRIPTION" \ | ||
| --arg area "$ADO_AREA_PATH" \ | ||
| --arg iter "$ADO_ITERATION_PATH" \ | ||
| --arg assn "$DRI_EMAIL" \ | ||
| --arg tags "$ADO_TAG" \ | ||
| '[ | ||
| { "op":"add", "path":"/fields/System.Title", "value":$title }, | ||
| { "op":"add", "path":"/fields/System.Description", "value":$desc }, | ||
| { "op":"add", "path":"/fields/System.AreaPath", "value":$area }, | ||
| { "op":"add", "path":"/fields/System.IterationPath", "value":$iter }, | ||
| { "op":"add", "path":"/fields/System.AssignedTo", "value":$assn }, | ||
| { "op":"add", "path":"/fields/System.Tags", "value":$tags } | ||
| ]' > /tmp/payload.json | ||
|
|
||
| AUTH=$(printf ":$ADO_PAT" | base64 | tr -d '\n') | ||
| WORK_ITEM_URL="https://dev.azure.com/${ADO_ORG}/${ADO_PROJECT}/_apis/wit/workitems/\$User%20Story?api-version=7.1-preview.3" | ||
|
|
||
| curl --fail-with-body -sS \ | ||
| -H "Content-Type: application/json-patch+json" \ | ||
| -H "Authorization: Basic $AUTH" \ | ||
| -X POST \ | ||
| --data-binary @/tmp/payload.json \ | ||
| "$WORK_ITEM_URL" |
Comment on lines
+15
to
+23
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - uses: actions/setup-python@v4 | ||
| with: | ||
| python-version: "3.9" | ||
| - run: pip install -r dev-requirements.txt | ||
| - name: Run Pre-Commit | ||
| run: pre-commit run --all-files |
Comment on lines
+14
to
+24
| if: github.event_name == 'pull_request' | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - uses: actions/setup-python@v4 | ||
| with: | ||
| python-version: "3.9" | ||
| - name: Check Pull Request Size | ||
| run: | | ||
| git fetch origin ${{ github.event.pull_request.base.ref }} --quiet # Need to manually fetch base branch in CI | ||
| python ./.github/scripts/commit-filesize-diff-summary.py --limit 1MB origin/${{ github.event.pull_request.base.ref }}..HEAD |
| var previousResponseId = LoadPreviousResponseId(conversationId); | ||
| if (previousResponseId != null) | ||
| { | ||
| _logger.LogInformation("Continuing conversation {ConversationId} with previous_response_id: {PreviousResponseId}", conversationId, previousResponseId); |
| var previousResponseId = LoadPreviousResponseId(conversationId); | ||
| if (previousResponseId != null) | ||
| { | ||
| _logger.LogInformation("Continuing conversation {ConversationId} with previous_response_id: {PreviousResponseId}", conversationId, previousResponseId); |
| } | ||
| catch (Exception ex) | ||
| { | ||
| _logger.LogWarning(ex, "Failed to load previous_response_id for conversation {ConversationId}", conversationId); |
| var dir = GetResponseStoreDir(); | ||
| Directory.CreateDirectory(dir); | ||
| File.WriteAllText(GetResponseIdFilePath(conversationId), responseId); | ||
| _logger.LogDebug("Saved response_id {ResponseId} for conversation {ConversationId}", responseId, conversationId); |
| } | ||
| catch (Exception ex) | ||
| { | ||
| _logger.LogWarning(ex, "Failed to save response_id for conversation {ConversationId}", conversationId); |
Member
|
Closing — sync run 26197833712 failed at the merge step because force_full=true produces an orphan-history branch that GitHub rejects for rebase merge. Fix in microsoft-foundry/foundry-samples-pr#346 (squash fallback in wait-and-merge.sh). A fresh sync will be dispatched once that lands. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated sync from private repo.
Synced commits: 43
Authors: Adi Yadav,Ankit Sinha Antriksh Jain,Ben Thomas Brandon Miller,Copilot Dooriya Li,Eamon O'Reilly Haflidi Fridthjofsson,Hameed Kunkanoor Hui Miao,Jian Miao Johan Stenberg,Kuojian Lu Lakshmi Naarayanan Ramakrishnan,Linda Li Meera Kurup,Roger Barreto Sanjeev Jagtap,Sheri Gilley Tao Chen,saanikaguptamicrosoft
Validation gate: mode=
none; tracked=0; blocked=0.Rollback point:
21fe22194885910ba82e85c073207c823e6c8f4d— to revert, force-push this SHA tomainand clear the sync-marks cache.Triggered by:
workflow_dispatchRun: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/26197833712