feat(platform-auth): add functions to manage platform auth pod restar…

[CasLubbers]

📌 Summary

Will restart all platformAuth pods when the apl-platform-auth-restart-state CM does not exist. This is checked on every reconcile run.

🔍 Reviewer Notes

Observe following logs being written when you install APL:

2026-08-04T12:58:08.920Z otomi:operator:apl-operator:info oauth2-proxy is healthy, restarting platform-auth pods
2026-08-04T12:58:08.943Z otomi:restartPlatformAuthPods:info Found 5 pods labelled otomi.io/auth=platform
2026-08-04T12:58:08.944Z otomi:restartPlatformAuthPods:info Restarting deployment argocd-server in namespace argocd
2026-08-04T12:58:09.000Z otomi:restartPlatformAuthPods:info Successfully restarted deployment argocd-server
2026-08-04T12:58:09.000Z otomi:restartPlatformAuthPods:info Restarting deployment harbor-portal in namespace harbor
2026-08-04T12:58:09.050Z otomi:restartPlatformAuthPods:info Successfully restarted deployment harbor-portal
2026-08-04T12:58:09.051Z otomi:restartPlatformAuthPods:info Restarting StatefulSet prometheus-po-prometheus in namespace monitoring
2026-08-04T12:58:09.126Z otomi:restartPlatformAuthPods:info Successfully restarted StatefulSet prometheus-po-prometheus
2026-08-04T12:58:09.127Z otomi:restartPlatformAuthPods:info Restarting deployment tekton-dashboard in namespace team-demo
2026-08-04T12:58:09.177Z otomi:restartPlatformAuthPods:info Successfully restarted deployment tekton-dashboard
2026-08-04T12:58:09.177Z otomi:restartPlatformAuthPods:info Restarting deployment tekton-dashboard in namespace tekton-dashboard
2026-08-04T12:58:09.218Z otomi:restartPlatformAuthPods:info Successfully restarted deployment tekton-dashboard
2026-08-04T12:58:09.218Z otomi:restartPlatformAuthPods:info Restarted 5 workloads with platform-auth pods

Observe following CM is written when restart has happend:
apl-platform-auth-restart-state

🧹 Checklist

• Code is readable, maintainable, and robust.
• Unit tests added/updated

[Copilot]

Pull request overview

Adds a one-shot “platform auth pod restart” mechanism to the operator’s successful apply path, gated on oauth2-proxy’s ArgoCD health and persisted via a marker ConfigMap, to mitigate Istio JWKS caching issues described in the new ADR.

Changes:

• Add marker ConfigMap helpers to detect/record that the platform-auth restart has already been performed.
• Extend AplOperator.runApplyIfNotBusy() to (non-blockingly) restart otomi.io/auth=platform workloads once oauth2-proxy is Healthy, then write the marker.
• Introduce a runtime-upgrade helper that finds platform-auth pods cluster-wide and restarts each distinct workload once, with unit tests and ADR documentation.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/operator/k8s.ts	Adds marker ConfigMap read/create helpers for the one-shot restart state.
src/operator/k8s.test.ts	Adds unit tests for the new marker helpers.
src/operator/apl-operator.ts	Hooks the restart check+action into the successful apply path, gated on ArgoCD health and marker state.
src/operator/apl-operator.test.ts	Adds tests verifying restart behavior and that apply success is not blocked by restart-check failures.
src/common/runtime-upgrades/restart-platform-auth-pods.ts	Implements pod discovery by label selector and workload-deduped restart using existing restart primitives.
src/common/runtime-upgrades/restart-platform-auth-pods.test.ts	Adds unit tests for label selection and restart deduplication.
adr/index.md	Registers the new ADR entry.
adr/2026-08-04-restart-platform-auth-pods-after-oauth2-proxy-healthy.md	Documents rationale/approach for the one-shot restart behavior.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/operator/k8s.test.ts:233

• markPlatformAuthPodsRestarted has a code path that intentionally ignores ConfigMap creation conflicts (ApiException 409), but the unit tests only cover the successful create. Adding a test for the 409 case will lock in the intended idempotent behavior (important when multiple operator instances race).

  test('creates the marker configmap', async () => {
    mockCoreV1Api.createNamespacedConfigMap.mockResolvedValue({})

    await markPlatformAuthPodsRestarted('test-namespace', 'apl-platform-auth-restart-state')

    expect(mockCoreV1Api.createNamespacedConfigMap).toHaveBeenCalledWith({
      namespace: 'test-namespace',
      body: { metadata: { name: 'apl-platform-auth-restart-state' } },
    })
  })
})

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/operator/apl-operator.ts:140

• The restart marker check and write are separated (read in needsPlatformAuthPodsRestart(), then create in restartPlatformAuthPods()), which is non-atomic. If two operator instances ever run concurrently, both can observe the marker missing and both can restart pods before one of them creates the ConfigMap, violating the “exactly once” requirement from the ADR.

Consider using the ConfigMap create as the gate/lock (e.g., attempt create first and skip on 409), or introducing an explicit lock/status field (in-progress/done) so concurrent instances don’t both restart while still allowing retries when a restart attempt fails.

  private async needsPlatformAuthPodsRestart(): Promise<boolean> {
    if (await hasPlatformAuthPodsRestarted()) return false
    await checkArgoCDAppStatus(OAUTH2_PROXY_ARGOCD_APP_NAME, k8s.custom(), 'health', 'Healthy')
    return true
  }

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (2)

src/common/runtime-upgrades/restart-platform-auth-pods.ts:27

• restartPlatformAuthPods aborts the whole restart sequence if restartPodOwner throws for any single pod (e.g. restartPodOwner can propagate errors from deletePod for Tekton-managed pods). This can leave the cluster in a partially-restarted state and also prevents the restart marker from being written, causing repeated restarts on subsequent applies.

  for (const pod of pods) {
    const workloadKey = deps.getWorkloadKeyFromPod(pod)
    if (workloadKey && restartedWorkloads.has(workloadKey)) continue

    await deps.restartPodOwner(pod, d, parsedArgs)

src/operator/apl-operator.ts:117

• PR description says the marker check happens “on every reconcile run”, but the implementation runs after every successful apply for both Poll and Reconcile triggers. Please align either the description or the code so operators know when to expect the one-shot restart to run (and to avoid surprising restarts during the poll loop).

      try {
        // See adr/2026-08-04-restart-platform-auth-pods-after-oauth2-proxy-healthy.md
        if (await this.needsPlatformAuthPodsRestart()) {
          await this.restartPlatformAuthPods()
        }

[merll]

Declared here, but it seems to be exclusively used in apl-operator.ts. Would consider moving it and skip the import.

[merll]

Would prefer skipping the APL_ prefix. The id is quite long as it is.

[merll]

Just minor comments on naming / placing things.

[merll]

Seeing this after an installation however.

Update: Coincidentally checked right after installation, where OAuth2-Proxy was up, but the App had not been marked as healthy yet. The restart triggered a few seconds after.