Skip to content

v3.4.1

Choose a tag to compare

@placerda placerda released this 11 Jul 23:55
f63c929

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-GptRagAppConfiguration in scripts/postProvision.ps1 now stamps six additional keys under the gpt-rag label with defaults that match the Jinja template (config/search/search.settings.j2):
    • WORK_IQ_ENABLED=false
    • WORK_IQ_KNOWLEDGE_SOURCE_NAME=""
    • FABRIC_IQ_ENABLED=false
    • FABRIC_IQ_KNOWLEDGE_SOURCE_NAME=""
    • FABRIC_IQ_WORKSPACE_ID=""
    • FABRIC_IQ_ONTOLOGY_ID=""
  • Source of truth remains the azd environment (Get-OptionalEnvValue), matching the existing FOUNDRY_IQ_* seeding block. Operators who set the azd env values before azd provision (or before azd 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 to v3.4.0 when 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/plain call used by the updated Set-GptRagAppConfiguration function, and verified with az 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. az reported "Target configuration already contains all configuration settings in source. No changes will be made." and lastModified timestamps stayed unchanged, confirming no needless writes.
  • Full azd provision was attempted in swedencentral, westus3, northeurope, eastus2, and eastus; Azure returned AKSCapacityHeavyUsage for 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 pure az 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