Skip to content

fix(jobs): shorten job names over the 63-byte label limit - #565

Merged
sylr merged 1 commit into
mainfrom
fix/jobs-name-length
Oct 28, 2026
Merged

sylr merged 1 commit into
mainfrom
fix/jobs-name-length

Conversation

@sylr

@sylr sylr commented Oct 28, 2026

Copy link
Copy Markdown
Contributor

Problem

jobs.Handle names each Job <owner-uid>-<name>. The Job controller copies the Job name into the job-name label, and label values are capped at 63 bytes. Any longer name is rejected:

spec.template.labels: Invalid value: "120b264e-5be3-49a8-bd4a-71e2ea097ae3-create-topic-reconciliation": must be no more than 63 characters

A Broker in OneStreamByService mode creates one create-topic-<service> Job per service. With a 36-byte UID, any service name of 14 characters or more goes over the limit, including reconciliation and transactionplane.

Seen on: stack hmaetndfmrqv-zdll on jupiter-staging-apse1-01. Its Broker has failed every reconcile since 2026-10-05, when the staging chart moved reconciliation to v2.5.1, past the v3 cutoff. That added a reconciliation stream. As a result, Reconciliation is stuck on v2.3.1, and Webhooks waits on its broker consumer. A production stack with legacy streams would hit the same problem on its first reconciliation upgrade past v2.4.0.

Changes

  • internal/resources/jobs/job.go: new jobs.Name(owner, jobName), which Handle now uses.
    • Names of 63 bytes or fewer are unchanged, so existing Jobs keep their names and are not run again.
    • Longer names are cut to 54 bytes and suffixed with - and 8 hex characters of a SHA-256 of the full name. The result is stable and starts with the owner UID.
  • internal/resources/jobs/name_test.go: unit tests at 63 bytes, 64 bytes and much longer. They check that the result is stable, a valid label value and a valid object name, and that two long names with the same prefix stay distinct.
  • internal/tests/jobs_controller_test.go: an envtest spec that runs Handle with create-topic-reconciliation (64 bytes in full) and checks that the Job is created and owned by the module. On the old naming, this spec fails with the error above.
  • docs/09-Configuration reference/settings.catalog.json: regenerated by just pre-commit. Only the job.go line numbers change.

Rollout

No action is needed. Jobs whose names fit already keep their names. Jobs whose names were too long never existed, so they are created under the new name on the next reconcile. zdll's Broker should become ready once this release is deployed to jupiter staging.

Testing

  • go test -race ./internal/resources/... passes.
  • ginkgo ./internal/tests/: 161 of 161 specs pass.

jobs.Handle names each Job <owner-uid>-<name>. The Job controller copies
that name into the job-name label, capped at 63 bytes, so any name over
63 bytes is rejected by the apiserver and the owner never becomes ready.

A Broker in OneStreamByService mode creates create-topic-<service> jobs:
36 + 1 + 27 = 64 bytes for reconciliation. Stack hmaetndfmrqv-zdll on
jupiter-staging-apse1-01 has had its Broker failing every reconcile since
reconciliation moved past v2.4.0 on 2026-10-05, blocking Reconciliation
and Webhooks.

Names over the limit are now truncated and suffixed with 8 hex characters
of a SHA-256 of the full name. Names within the limit are unchanged.

Constraint: Existing Jobs are found by name, so names that already fit must not change
Rejected: Hash every job name | would rename every existing Job and re-run completed ones
Rejected: Shorten create-topic-<service> in the broker only | other owners can hit the same limit
Confidence: high
Scope-risk: narrow
Directive: Look up Jobs created by Handle with jobs.Name, never by rebuilding <uid>-<name>
Not-tested: zdll itself; the stuck job is created on the first reconcile after the rollout
@sylr
sylr requested a review from a team as a code owner October 28, 2026 14:13
@NumaryBot NumaryBot added risk: medium NumaryBot classified this pull request as medium risk. bot-reviewed review-approved The NumaryBot review gate is satisfied for the current head. labels Oct 28, 2026

@NumaryBot NumaryBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The required automated review completed with no remaining findings.

@sylr
sylr merged commit 9a4bd38 into main Oct 28, 2026
20 checks passed
@sylr
sylr deleted the fix/jobs-name-length branch October 28, 2026 14:43
@sylr sylr mentioned this pull request Oct 28, 2026
sylr added a commit that referenced this pull request Oct 28, 2026
Bump the operator and operator-crds Helm charts to 3.21.0 with
appVersion v3.21.0 and regenerate the operator chart dependency lock.

Minor bump requested; main carries only fixes since v3.20.0 (#564, #565).

Confidence: high
Scope-risk: narrow
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot-reviewed review-approved The NumaryBot review gate is satisfied for the current head. risk: medium NumaryBot classified this pull request as medium risk.

Development

Successfully merging this pull request may close these issues.

3 participants