fix(istio): read action identity/parameters from ACTION_* env vars - #5
Draft
serialito74 wants to merge 2 commits into
Draft
fix(istio): read action identity/parameters from ACTION_* env vars#5serialito74 wants to merge 2 commits into
serialito74 wants to merge 2 commits into
Conversation
…utes build_context checked .service.attributes.X // .parameters.X, but on a create action .service.attributes already exists with empty-string values (not null) for every schema property, so jq's // never falls through to .parameters - the just-submitted form values (base_domain, path_prefix, scope) are silently discarded and the action fails with "base_domain is required" even when the field is explicitly filled in the UI. Switched to a merge where parameters win, which still resolves correctly on update actions (unset parameters fall back to the already- persisted service attributes).
serialito74
marked this pull request as draft
August 25, 2026 15:52
Verified live against a real cluster that the previous commit's merge fix (parameters win over stale attributes) was not actually the root cause: $CONTEXT (from `--build-context`) never carries the action's own id/slug/parameters/service data at all on the currently-shipping np CLI - that JSON only carries related entities (scope/application/ namespace/account; "service" isn't even a valid --include resource). Confirmed via a full env-var-name dump on a live failed action that the action's own identity and submitted create-form values arrive as flat ACTION_* environment variables instead, set directly by `np service workflow exec` (ACTION_PARAMETERS_BASE_DOMAIN, ACTION_SERVICE_ID, ACTION_ENTITY_NRN, ACTION_SERVICE_DIMENSIONS_ENVIRONMENT, etc.) - not through $CONTEXT at all. - build_context: read SERVICE_ID/SERVICE_SLUG/ACTION_ID/ACTION_NAME/ APPLICATION_ID/BASE_DOMAIN/STRIP_PREFIX/PATH_PREFIX/SCOPE_SLUG directly from the corresponding ACTION_* env vars. - fetch_provider_data: same root cause was behind a `jq: null has no keys` error on every single run (.service.dimensions/.entity_nrn don't exist in $CONTEXT either). Reads ACTION_ENTITY_NRN and ACTION_SERVICE_DIMENSIONS_ENVIRONMENT instead. End-to-end verified: a real create action now completes successfully and the HTTPRoute gets applied to the cluster.
serialito74
changed the title
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
2 participants
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.
Summary
Updated: the initial version of this PR merged
.service.attributes/.parameterswith parameters winning, based on the assumption that$CONTEXTcarried the action's own submitted values but a jq//footgun was masking them. That assumption was wrong — verified live against a real cluster that it did not fix the issue.Root cause, confirmed live:
$CONTEXT(fromnp service workflow exec --build-context) never carries the action's own id/slug/parameters/service data on the currently-shippingnpCLI — that JSON only carries related entities (scope/application/namespace/account, per the CLI's own--includeoption list, which doesn't even have"service"as a valid value).A full environment-variable-name dump on a live failed create action showed the action's own identity and submitted create-form values arrive as flat
ACTION_*environment variables instead, set directly bynp service workflow exec:ACTION_ID,ACTION_SLUG,ACTION_ENTITY_NRNACTION_SERVICE_ID,ACTION_SERVICE_SLUG,ACTION_SERVICE_DIMENSIONS_ENVIRONMENTACTION_PARAMETERS_<FIELD>(the submitted create-form values, e.g.ACTION_PARAMETERS_BASE_DOMAIN)ACTION_TAGS_<TAG>(ACTION_TAGS_APPLICATION_ID, etc.)Confirmed
base_domain/path_prefix/scopewere present and correct in these env vars while$CONTEXThad none of.service,.parameters,.id, or.slug.Fix
build_context: readsSERVICE_ID/SERVICE_SLUG/ACTION_ID/ACTION_NAME/APPLICATION_ID/BASE_DOMAIN/STRIP_PREFIX/PATH_PREFIX/SCOPE_SLUGdirectly from the correspondingACTION_*env vars, dropping the$CONTEXT-based extraction entirely.fetch_provider_data: the same root cause was behind ajq: null has no keyserror on every single run (.service.dimensions/.entity_nrndon't exist in$CONTEXTeither) — readsACTION_ENTITY_NRN/ACTION_SERVICE_DIMENSIONS_ENVIRONMENTinstead.Test plan
ERROR: base_domain is requirednow completes with exit status 0, and theHTTPRouteis actually applied to the cluster.$CONTEXTvsACTION_*mismatch affects other--build-context-consuming scripts/services in this org, since it isn't specific to path-router.