Write Redis cache settings during post-deployment configuration

[Paul Lizer (paullizer)]

Summary

postconfig.py provisioned and RBAC-granted a Redis cache but never wrote the settings the application reads. The Redis section was a placeholder:

# Scale > Redis Cache
# todo support redis cache configuration

Impact

configure_sessions() in application/single_app/app.py reads enable_redis_cache and redis_url from the Cosmos settings document. The App Service only receives REDIS_ENTRA_TOKEN_SCOPE from Bicep, nothing else.

So on a deployment with deployRedisCache: true, after provisioning succeeded, the settings document still read:

enable_redis_cache = False
redis_url          = ${chr(39)}${chr(39)}
redis_port         = ${chr(39)}${chr(39)}

The cache was billed and running, the managed identity role assignment was in place, and the application silently used filesystem sessions and in-memory caching instead. There was no error, which is why this was easy to miss.

Observed on a fresh Azure Managed Redis deployment (Balanced_B0, HA enabled) in North Central US.

Fix

postconfig now writes enable_redis_cache, redis_url, redis_auth_type, redis_service_type, redis_port and redis_key.

Two deliberate choices:

1. Guarded by if redis_cache_host_name: so an operator-configured external Redis is not overwritten when deployRedisCache is false.
2. The service type is translated, not passed through. Bicep redisCacheKind uses managed/classic; the application uses azure_managed_redis/azure_cache_for_redis. Writing the Bicep value through unchanged would fail resolve_redis_service_type() and resolve the wrong TLS port - 6380 instead of 10000 for Managed Redis.

redis_key is set from core_service_keys, which is empty under managed identity. That also clears a stale key left by an earlier key-auth deployment.

Tests

Adds functional_tests/test_postconfig_redis_cache_configuration.py:

• asserts every setting the application reads is written, and that the placeholder is gone
• asserts the guard is present
• parses the SERVICE_TYPE_* constants out of functions_redis_client.py and asserts postconfig emits those exact values, so the deployer and application vocabularies cannot drift apart again

Results: 2/2 tests passed

Unrelated pre-existing failure

functional_tests/test_postconfig_azurecli_credential.py currently fails on Development before this change. It expects client = CosmosClient(cosmosEndpoint, cosmosKey) but the code was refactored to azure_cosmos.CosmosClient(...). Left alone to keep this PR scoped - happy to fix separately.

deployers/version.txt bumped to 1.0.30.