15b (Terraform BYO-VNet): account capability host provisioning times out (~2.5h) with CapabilityHostOperationFailed; sample omits the account-level capability host required by docs

[andreireznikau]

Summary

Following the 15b private-network standard agent setup (Terraform) sample for a BYO-VNet Foundry deployment, the account-level capability host consistently fails with a platform-side timeout after ~2.5 hours:

CapabilityHostOperationFailed: "The resource provision operation did not complete
within the allowed timeout period."

All prerequisites documented in Set up private networking for Foundry Agent Service have been verified as satisfied (details below), and the failure reproduces on both the platform's auto-created capability host and an explicitly created one — including after a full delete → purge → recreate cycle of the account.

Additionally, the 15b Terraform sample appears inconsistent with both the official docs and the equivalent Bicep sample regarding the account-level capability host (see "Sample/docs gaps" below).

Environment

• Region: Sweden Central
• Account: Microsoft.CognitiveServices/accounts kind AIServices, created via azapi_resource @ 2025-06-01 with allowProjectManagement = true, public network access disabled
• networkInjections: scenario = "agent", BYO subnet, useMicrosoftManagedNetwork = false — set atomically at account create time, matching the 15b sample
• Agent subnet: 10.0.8.0/24, dedicated to this account, delegated to Microsoft.App/environments, no NSG/UDR/firewall restrictions
• The account provisions Succeeded with the correct networkInjections visible in the GET response

What happens

The capability host PUT is accepted, the associated ACA managed environment operations succeed, and then the AML RP times out internally roughly 2.5 hours later. Reproduced consistently across all attempts:

1. Platform's auto-created capability host <account>@aml_aiagentservice (triggered by networkInjections at account creation) — OperationTimeout
2. Explicit account capability host via azapi_resource (capabilityHostKind = "Agents", customerSubnet matching the account's networkInjections subnet) — same timeout
3. After deleting and purging the account and recreating it fresh with the subnet association at create time (per the documented limitation that network injection cannot be added to an existing account), with the explicit account capability host including customerSubnet — same timeout

Since even the platform's own auto-created capability host fails identically across a clean account lifecycle, this does not appear to be a client-side configuration problem.

Prerequisites verified (all satisfied)

Check	Result
Resource providers	Microsoft.App, Microsoft.ContainerService, Microsoft.CognitiveServices (and the other providers listed in the prerequisites) all Registered
Subnet address space	10.0.8.0/24 — Sweden Central is in the documented Class-A (10.0.0.0/8) supported region list
Subnet delegation & size	Microsoft.App/environments, /24 (recommended size), serviceAssociationLinks: null (no stale links)
Agent subnet exclusivity	Subnet dedicated to this single Foundry resource
Clean account lifecycle	Previous failed account was deleted and purged before recreation; injection configured at create time per the documented limitation
NSG / UDR / firewall	None; default AllowInternetOutBound active; intra-VNet 443 to private endpoints allowed; no TLS inspection
Private DNS	Account PE A-record resolves; privatelink.services.ai.azure.com / privatelink.cognitiveservices.azure.com / privatelink.openai.azure.com and storage/cosmos/search zones linked to the VNet
Account state	provisioningState: Succeeded, correct networkInjections (useMicrosoftManagedNetwork: false)
Region	Account and VNet both in Sweden Central

Sample/docs gaps observed along the way

1. The 15b Terraform sample creates no account-level capability host, while:

   • the capability hosts concept doc states "You can't create a project capability host unless an account-level capability host already exists", and
   • the Bicep equivalent (15, add-account-capability-host.bicep) creates it explicitly.

   The Terraform sample presumably relies on the caphost auto-created by networkInjections — which is exactly the resource that times out in our environment, leaving no working path. Should the Terraform sample create the account capability host explicitly, as Bicep does?

2. customerSubnet is required but undocumented. On a BYO-VNet account, creating the account capability host without customerSubnet returns 400 "customerSubnet must match the subnet recorded on the Foundry account". The Bicep sample sets it, but the capability hosts concept doc's account-level example body is only {"capabilityHostKind": "Agents"} with no mention of customerSubnet anywhere on Learn.

3. Minor: creating a capability host named <account>@aml_aiagentservice via the Terraform azapi provider fails client-side on the @ character (a plain az rest PUT accepts the same name). Worth a note in the sample if the canonical name is preferred, though per the concept doc's naming rules any name works on an empty scope.

Questions

1. What else can cause the CapabilityHostOperationFailed timeout (the docs' catch-all "Failed to create Aml RP virtual workspace") when every documented prerequisite is verified? Is there any diagnostic visibility into the agent-environment provisioning, or is a support ticket the only path? (Happy to provide operationIds and resource IDs privately.)
2. Can the 15b Terraform sample be updated per gap Update README.md #1 (explicit account capability host with customerSubnet)?
3. Can customerSubnet be documented on the capability hosts concept page (gap ci: Migrate test infrastructure fromr azureai-samples #2)?