Skip to content

Automated sync from private repo (2026-05-22)#722

Merged
foundry-samples-repo-sync[bot] merged 3 commits into
mainfrom
sync/private-to-public-20260522-072112
May 22, 2026
Merged

Automated sync from private repo (2026-05-22)#722
foundry-samples-repo-sync[bot] merged 3 commits into
mainfrom
sync/private-to-public-20260522-072112

Conversation

@foundry-samples-repo-sync
Copy link
Copy Markdown
Contributor

Automated sync from private repo.

Synced commits: 3
Authors: Hui Miao,Mahya Gheini Tao Chen

Validation gate: mode=none; tracked=17; blocked=0.

Rollback point: 91a02c7ea64ebec4c4ebd94e495e3d6a5f413d6a — to revert, force-push this SHA to main and clear the sync-marks cache.

Triggered by: schedule
Run: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/26274124744

m-gheini and others added 3 commits May 21, 2026 08:57
* Applied existng vnet fixes and added cleanup scripts for easy resource cleanup

* Minor updates

* remove deployment-tools from template fixes PR (will be separate PR)
* Add MAF RAG, Skills, Memory samples

* Remove auto generated files

* Fix tests

* Fix tests

* Narrow requirements.txt to direct subpackages

Replace the bare `agent-framework` meta-package in the requirements of the
new RAG, Skills and Memory samples (11/12/13) with the dedicated subpackages
those samples actually import:

- `agent-framework-foundry` (provides `Agent`, `SkillsProvider`,
  `FoundryChatClient`, `FoundryMemoryProvider`, and pulls in
  `azure-ai-projects` transitively for the SDK clients used by the
  bootstrap/provisioning scripts)
- `agent-framework-azure-ai-search` (sample 11 only — provides
  `AzureAISearchContextProvider`)
- `agent-framework-foundry-hosting` (provides `ResponsesHostServer`)
- `azure-ai-projects` kept explicit on 12 and 13 because their
  `main.py` / provisioning scripts import `azure.ai.projects` directly.

The bare `agent-framework` package requires `agent-framework-core[all]`,
which on Linux x86_64 (the `python:3.12-slim` container build) activates
the full optional dependency set including `agent-framework-hyperlight`
and its native `hyperlight-sandbox-backend-wasm` wheel. This wide
dependency surface caused the `pip install -r requirements.txt` step for
sample 12 to fail with `ResolutionImpossible` in the Hosted Agents
Foundry Extension E2E pipeline. Narrowing each sample's requirements to
the subpackages whose APIs it actually uses cuts the transitive install
from ~100 packages to ~30, removes the platform-specific wheels, and
follows the upstream "selective install" recipe documented in the
`agent-framework` README.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Treat un-substituted env-var placeholders as unset

The Foundry Ext E2E pipeline drives the Foundry VS Code extension to
deploy each sample without exporting the optional environment variables
the new RAG / Skills / Memory samples reference in their `agent.yaml`
(`AZURE_SEARCH_ENDPOINT`, `AZURE_SEARCH_INDEX_NAME`, `SKILL_NAMES`,
`MEMORY_STORE_NAME`). The extension's deploy-time substitution leaves
those references as literal `${VAR}` text on the running container
rather than empty strings, which breaks the samples' existing
"is the env var set?" checks:

- Sample 11 (`azure-search-rag`) constructs an
  `AzureAISearchContextProvider` with the literal `${AZURE_SEARCH_ENDPOINT}`
  endpoint. The container starts (`/readiness` passes) but every
  Responses request fails with `server_error: An internal server error
  occurred.` once the search call is made — observed as 43 retry
  attempts in the Foundry Ext E2E smoke test.
- Sample 12 (`foundry-skills`) splits `${SKILL_NAMES}` into a single
  non-empty entry and tries to download a skill named `${SKILL_NAMES}`
  from the Foundry `beta.skills` API at startup. The download
  exception crashes `main()` before `ResponsesHostServer.run_async()`
  binds `/readiness`, so every smoke request returns
  `424 session_not_ready`.
- Sample 13 (`foundry-memory`) currently survives the same situation
  because `FoundryMemoryProvider` happens to tolerate a bogus
  `memory_store_name` at query time, but the same latent bug is there.

Add a small `_resolved_env` helper to each sample that treats both
`${VAR}` and `{{VAR}}` template placeholders (as well as missing
and empty values) as "unset". The provider/bootstrap branch only runs
when the value is a real, substituted string, so the agent starts
cleanly and responds without the optional capability when those
resources aren't provisioned. The helper is intentionally duplicated
per sample so each sample remains self-contained.

For sample 12, also bound `_bootstrap_skills` with
`asyncio.wait_for(..., timeout=60)` so a slow or hung Foundry
`beta.skills` round-trip can't keep `/readiness` from returning 200
past the hosted-agent runtime's session-readiness timeout window.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Force JSON output from `azd ai agent show` in Cloud E2E

The recent `azd` CLI release changed `azd ai agent show --no-prompt`'s
default output from JSON to a human-readable two-column table, which
makes the `jq` filter on the responses-endpoint lookup fail with
`Invalid numeric literal at line 1, column 6` and abort every
responses-protocol invoke step with
`Could not resolve agent responses endpoint from 'azd ai agent show'`.

This has been failing on the `main` branch since 2026-05-18 and affects
all hosted-agent samples (the unchanged 10-downstream-azure sample fails
identically alongside the new 11/12/13 samples).

Pass `--output json` explicitly so `jq` gets the structure it expects.
This is the same flag the cleanup step on line 840 of this workflow
already uses for the same command.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Add test-payload.txt for samples 11, 12, 13

Provide per-sample Cloud E2E invoke prompts that exercise each new
sample's actual scenario, matching the convention used by samples
07-skills and 09-declarative-customer-support.

- 11-azure-search-rag: three retrieval prompts that target the
  return-policy, shipping-guide and tent-care documents seeded by
  provision_index.py, so a configured deployment can verify the
  RAG context provider actually pulled the indexed content.
- 12-foundry-skills: three customer-support prompts, including one
  injury+legal-action scenario that should trigger the
  escalation-policy skill, so a configured deployment can verify both
  the support-style voice and the escalation flow.
- 13-foundry-memory: three turns that share two user facts in turns
  1-2 and ask the agent to recall them in turn 3, so a configured
  deployment can verify the memory provider stored and retrieved the
  facts across the conversation.

Without the optional env vars set (the current CI environment) the
agent still answers each prompt using just the LLM, so these payloads
are also safe for runs that don't provision the search index / skills
/ memory store.

Addresses review feedback from ankitbko on PR #320.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Ed van Bruggen <edvan@github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: eavanvalkenburg <github@vanvalkenburg.eu>
@foundry-samples-repo-sync foundry-samples-repo-sync Bot merged commit 6ef684d into main May 22, 2026
7 checks passed
@foundry-samples-repo-sync foundry-samples-repo-sync Bot deleted the sync/private-to-public-20260522-072112 branch May 22, 2026 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants