[Helm 2.3.0] Digest-pinned orchestrator image becomes invalid 64-character Pod label

Helm Chart Version

Chart 2.3.0; appVersion 2.3.0; official Helm V2 chart. Kubernetes (K3s v1.35.8+k3s1), linux/amd64.

What step the error happened?

During the Sync

Relevant information

We need a supported correction for Airbyte Core 2.3.0 on Helm V2 and Kubernetes, while preserving digest-pinned container images.

The launcher parses the image version with substringAfterLast(":", "latest"). Given airbyte/container-orchestrator:2.3.0@sha256:845e7e3ea927268aa3a9324d5beade8d862291b75be11e6a6d0e4d0f847a9c17, it puts the 64-character digest in orchestrator_image_version. Kubernetes rejects the replication Pod because label values may not exceed 63 characters. The replication Pod does not start. We also observed the native job report succeeded with zero records after this rejection.

The affected launcher is airbyte/workload-launcher@sha256:0e18b1abcda6c9d99cb42085816e555bfee085f4b0c6329c3616a2f9cf5fd076. Its linux/amd64 manifest is sha256:c425d7ed79334e667ae4e4e27b9c69657d41bc01985ff5b9b8f0a90a79f6b978. The packaged io.airbyte-airbyte-workload-launcher-2.3.0.jar has SHA256 0588efe9ca21cf20dc05f1e26f7578020350984bf2dc7ef67fc8c0c7752f7ff0.

The image labels include io.airbyte.git-revision=8563a3b and io.airbyte.version=3.3.14, but also io.airbyte.app=airbyte-base-java-image. We cannot establish that those inherited-looking labels identify the actual launcher source. The revision does not resolve in airbytehq/airbyte-platform, and we found neither a public v2.3.0 source tag nor a 2.3.0 launcher source JAR in the public Maven repository we checked.

Current public PodLabeler source still shows the parser behavior. Draft PR450 addresses missing configured-label propagation, but its proposed precedence places generated image labels after configured labels, so it would not resolve this collision.

Can you provide either an official compatible patched launcher image, or the exact public source commit and reproducible build instructions for the shipped 2.3.0 launcher? The desired correction changes only display metadata; the actual container image must retain its full immutable digest. We do not want to disable Kubernetes validation, unpin images, or rebuild from an unrelated current branch.

Observed reproduction sequence:

1. Configure workloadLauncher.containerOrchestrator.image with the full tag@sha256:digest reference above.
2. Start an otherwise configured replication sync.
3. The workload launcher generates orchestrator_image_version from the digest rather than the tag. Kubernetes rejects Pod creation before replication starts.

Expected: valid Kubernetes metadata while the actual container image reference remains digest-pinned.

Related, but not the same defect: https://github.com/airbytehq/airbyte/issues/33068 and https://github.com/airbytehq/airbyte-platform/pull/450.

Public source inspected: https://github.com/airbytehq/airbyte-platform/blob/8182f5cb1f2c0ef3174b4c657a68afff5b1b4d90/airbyte-workload-launcher/src/main/kotlin/pods/PodLabeler.kt (getImageMetadataPair). This public snapshot is corroborating evidence, not a claim that it is the exact shipped source.

Relevant log output

Sanitized failure detail: Kubernetes HTTP 422 at metadata.labels; the generated 64-character digest value exceeds the 63-byte label-value limit ("must be no more than 63 bytes"). No private logs, account identifiers, or credentials are attached.

AGENT GENERATED: by gpt-6-astra