v3.4.1
Patch release. scripts/postProvision.ps1 now seeds the WORK_IQ_* and FABRIC_IQ_* App Configuration keys during provision, so operators can flip Work IQ or Fabric IQ on from the App Configuration blade without having to discover the key names first or run az appconfig kv set from scratch.
Who is affected
Operators enabling Work IQ or Fabric IQ on an already-provisioned environment. Before this release, only the FOUNDRY_IQ_* keys were seeded explicitly by the post-provision hook; the WORK_IQ_* and FABRIC_IQ_* keys were only written as a side-effect of config/search/setup.py rendering search.settings.j2. Since the template reads its context from App Configuration itself, on the first render the keys did not exist and defaulted to false, then got written back as false. Flipping either feature on required manually creating the keys with az appconfig kv set and re-running config/search/setup.py (or azd hooks run postprovision).
Changed
Set-GptRagAppConfigurationinscripts/postProvision.ps1now stamps six additional keys under thegpt-raglabel with defaults that match the Jinja template (config/search/search.settings.j2):WORK_IQ_ENABLED=falseWORK_IQ_KNOWLEDGE_SOURCE_NAME=""FABRIC_IQ_ENABLED=falseFABRIC_IQ_KNOWLEDGE_SOURCE_NAME=""FABRIC_IQ_WORKSPACE_ID=""FABRIC_IQ_ONTOLOGY_ID=""
- Source of truth remains the azd environment (
Get-OptionalEnvValue), matching the existingFOUNDRY_IQ_*seeding block. Operators who set the azd env values beforeazd provision(or beforeazd hooks run postprovision) still get their choices stamped into App Configuration. - No breaking changes. With every value defaulting to
false/"", existing environments upgrade with no behavior change; the deployed and rendered search resources are identical tov3.4.0when no feature flag is flipped.
Component versions
The following component versions are pinned for this release:
| Component | Version |
|---|---|
| gpt-rag-ui | v2.3.13 |
| gpt-rag-orchestrator | v3.3.0 |
| gpt-rag-ingestion | v2.4.14 |
| infra / AI Landing Zone | v2.3.0 |
Validation
- Targeted App Configuration validation in a throwaway Standard-mode resource group: fresh App Configuration resource created, the six new keys imported via the exact
az appconfig kv import --format json --label gpt-rag --content-type text/plaincall used by the updatedSet-GptRagAppConfigurationfunction, and verified withaz appconfig kv list. All six keys were present with the expected defaults (WORK_IQ_ENABLED=false,FABRIC_IQ_ENABLED=false, everything else empty string). - Idempotency: re-ran the import against the seeded App Configuration.
azreported "Target configuration already contains all configuration settings in source. No changes will be made." andlastModifiedtimestamps stayed unchanged, confirming no needless writes. - Full
azd provisionwas attempted inswedencentral,westus3,northeurope,eastus2, andeastus; Azure returnedAKSCapacityHeavyUsagefor the Container Apps environment in every region during this window and blocked full-stack validation. The affected code path is the App Configuration seeding step only, which is pureaz appconfig kv import, so targeted validation against a standalone App Configuration resource is representative. Full-stack regression will run on the next release-cycle deployment when regional capacity clears.
References
- Issue: Azure/gpt-rag#551
- PR: Azure/gpt-rag#553 (merges #552)