EasyAuth sidecar authenticates session cookie but forwards requests without x-ms-client-principal headers, ~18–25 min after replica start (middleware 1.12.9.0)

[yduran84]

Summary

Our Container App uses built-in authentication (Entra ID, RedirectToLoginPage, no token store).
Three times in one evening (2026-08-19, eastus2, consumption plan), the http-auth sidecar
entered a state where it successfully authenticated the session cookie and forwarded the request
to the app container with HTTP 200 — but attached no x-ms-client-principal* headers. Our app
fails closed on missing identity, so this presents as a total outage for signed-in users, while
/api/health (an excludedPath) stays green.

The strongest pattern: a time fuse

Each episode began a consistent 18–25 minutes after the serving replica's container start:

Episode	Refusals began (UTC)	Replica started	Minutes after start	Cleared by
1	20:42:24	20:17:57	24.4	revision restart
2	21:06:59	20:48:31	18.5	revision restart
3	21:50:52	21:32:44	18.1	replica replacement

Every pod replacement restored principal injection — for roughly one fuse-length.

Evidence from the sidecar's own telemetry

During episode 3, while our app received zero principal headers on every request, the sidecar's
MiddlewareConsoleLogs kept counting successes:

• 21:51:24 {"numberOfSuccessfulCookieAuthentications":27,"numberOfUniqueAuthenticatedUsers":1,...}
• 21:57:24 {"numberOfSuccessfulCookieAuthentications":26,"numberOfUniqueAuthenticatedUsers":1,...}

So the cookie decrypted and validated (this also rules out session-key loss — and a token store,
which we don't use, persists provider tokens and is not on the principal-injection path).
Anonymous requests still 302'd to Entra correctly throughout; the fault is specific to
authenticated forwarding. Requests during the failure carried 200s in the sidecar's request log
(Request finished ... 200), i.e. the sidecar believed it was doing its job.

What did NOT change

• App image: one episode began on an image that had been serving cleanly (and the same code path
  had received x-ms-client-principal-id on every authenticated request for months).
• Auth configuration: unchanged across the window (verified via az containerapp auth show).
• Middleware version: ModuleRuntimeVersion 1.12.9.0 since 2026-08-04 (from mcr.microsoft.com/appsvc/middleware:1.12.9.0),
  15 days of clean operation before onset — so either an unversioned image patch or a
  platform-side change around 2026-08-18/19 is implicated. We also observed a new
  x-ms-middleware-request-id request header appear on 2026-08-18, which we cannot correlate to
  any published change.
• Sidecar logs show zero warnings/errors/exceptions around any onset (swept 24 h of
  ContainerAppConsoleLogs for warn/fail/crit/Exception/DataProtection/key/token-refresh).

Environment

• Azure Container Apps, consumption, eastus2, single revision mode, 1 replica.
• Built-in auth: Entra ID (single tenant), unauthenticatedClientAction: RedirectToLoginPage,
  excludedPaths for health/static routes, no token store, no runtimeVersion pin.
• Sidecar: container http-auth, ModuleRuntimeVersion 1.12.9.0.

Ask

1. Is there a known regression in middleware 1.12.9.x (or a platform rollout around 2026-08-18)
   affecting principal-header injection after ~18–25 minutes of process lifetime?
2. Is platform.runtimeVersion honored on Container Apps authConfigs, and what values are valid,
   so affected apps can pin back?
3. We have full Log Analytics extracts (app refusals vs sidecar telemetry, per-minute) and can
   supply them.

Workaround we run today: a scheduled-query alert on our app's fail-closed refusal line
triggers a Logic App that restarts the latest revision — detection to recovery in a few minutes.

Related (not the same signature): #1393 (intermittent missing principal headers, ~10% of
requests), #1015 (intermittent login redirect failures). Ours is deterministic once entered, total
(100% of authenticated requests), and time-fused from replica start.