fix(k8s): add missing AUTH_JWT_SECRET to values-development.yaml - #6610
Merged
Conversation
The default values.yaml sets AUTH_JWT_SECRET in texeraEnvVars, but values-development.yaml overrides texeraEnvVars as a whole list and omitted it. Helm replaces lists rather than merging, so a local install with `-f values-development.yaml` drops AUTH_JWT_SECRET from every service. The computing-unit manager reads this variable via env.get(KEY).get when launching a Kubernetes computing unit, so the missing value makes CU creation fail hard with `java.util.NoSuchElementException: None.get` (HTTP 500 on POST /api/computing-unit/create). Any local k8s deployment hits this the moment a user tries to create a computing unit. Add AUTH_JWT_SECRET to the development values with the same development-only default as values.yaml, so all services share one consistent signing secret. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sk8aHo2kwTB86ULNSXyBdm
Contributor
Automated Reviewer SuggestionsBased on the
|
Contributor
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
aglinxinyuan
approved these changes
Jul 20, 2026
aicam
enabled auto-merge
July 20, 2026 19:34
Address review feedback: replace the random-looking hex dev secret with an obvious non-secret placeholder (all 'a', 64 chars / 512-bit) so it plainly reads as a throwaway local value and won't trip secret scanners. It stays a fixed shared string rather than empty or "random": every service must sign/verify with the same key, an empty value yields an invalid (0-length) HMAC key, and "random" generates a different key per pod (breaking cross-service auth). Production still overrides it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sk8aHo2kwTB86ULNSXyBdm
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.
What changes were proposed in this PR?
Adds the
AUTH_JWT_SECRETenvironment variable tobin/k8s/values-development.yaml.The default
values.yamlsetsAUTH_JWT_SECRETinsidetexeraEnvVars, butvalues-development.yamloverridestexeraEnvVarsas a whole list. Helm replaces lists rather than merging them, so a local install with-f values-development.yamlsilently dropsAUTH_JWT_SECRETfrom every Texera service.The computing-unit manager reads this variable directly via
env.get(KEY).getwhen launching a Kubernetes computing unit (ComputingUnitManagingResource.scala), so the missing value makes computing-unit creation fail hard:Any local Kubernetes deployment following the development values hits this the moment a user tries to create a computing unit. The fix adds the variable with the same development-only default already used in
values.yaml, so all services share one consistent JWT signing secret.Any related issues, documentation, discussions?
None — standalone bug fix in the development values overlay. Independent of any other in-flight
bin/k8swork.How was this PR tested?
Reproduced and verified on a local minikube cluster (
helm install ... -f values-development.yaml):java.util.NoSuchElementException: None.get.kubectl execinto the manager pod confirmedAUTH_JWT_SECRETwas unset.helm upgradewith this change):AUTH_JWT_SECRETis present on the manager (and all services), the manager rolled out cleanly, and theNone.geterror no longer occurs.Also confirmed the added value is byte-for-byte identical to the
AUTH_JWT_SECRETdefault invalues.yaml, so development and production use the same variable and the dev overlay stops diverging.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)