Repository navigation
fix(jobs): shorten job names over the 63-byte label limit - #565
Merged
Merged
Conversation
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
NumaryBot
approved these changes
Oct 28, 2026
NumaryBot
left a comment
Contributor
There was a problem hiding this comment.
The required automated review completed with no remaining findings.
flemzord
approved these changes
Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
jobs.Handlenames each Job<owner-uid>-<name>. The Job controller copies the Job name into thejob-namelabel, and label values are capped at 63 bytes. Any longer name is rejected:A Broker in
OneStreamByServicemode creates onecreate-topic-<service>Job per service. With a 36-byte UID, any service name of 14 characters or more goes over the limit, includingreconciliationandtransactionplane.Seen on: stack
hmaetndfmrqv-zdllon 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 areconciliationstream. 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: newjobs.Name(owner, jobName), whichHandlenow uses.-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 runsHandlewithcreate-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 byjust pre-commit. Only thejob.goline 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.