agentplat▸control runs deployments agents metering + agent
← runs

run_3b038b37e51906b3

SUCCEEDED retrigger →
jira-triage v1 · jira-triage-k8s · owner ingest:jira-new-ticket (api) · via jira-new-ticket · cloud-engineering

input

{
  "request": "Triage Jira ticket MZCLD-3774: MozCloud Helm charts: Gateway API HTTP-to-HTTPS redirect status code is hardcoded to 302 and cannot be disabled",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3774"
  ],
  "sourceContext": {
    "issue": "MZCLD-3774"
  }
}

summary

MZCLD-3774 is a well-documented, actionable bug/feature-gap report against the mozcloud-gateway Helm library and application chart. It correctly identifies two coupled issues: (1) the auto-generated HTTP→HTTPS redirect HTTPRoute hardcodes statusCode 302 instead of reading the already-defined default in _helpers.tpl, and (2) the application chart's values.schema.json blocks any per-host override of redirect behavior (additionalProperties: false on httpRoutes.rules[], plus no enabled/disable toggle outside type: internal). This creates a silent behavior regression for tenants migrating from GKE Ingress (which supports 301/302/303/307/308 via frontendConfig.redirectToHttps) to Gateway API (fixed at 302). FxA's migration (MZCLD-3567) is already working around this with a hand-rolled per-tenant HTTPRoute, which undermines the shared-chart goal and should be resolved before MZCLD-2323 (FxA MozCloud chart migration) proceeds. The ticket is currently in Backlog with no comments; it includes a concrete, reasonable proposed approach and correctly cross-references related tickets (MZCLD-3638, MZCLD-3773, MZCLD-2323, MZCLD-3567). Recommend prioritizing this ahead of/alongside MZCLD-2323 and MZCLD-3567 completion, and assigning an owner to implement the schema + template changes.

findings

  • none

proposed actions

none

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3774"
    },
    "result": {
      "key": "MZCLD-3774",
      "summary": "MozCloud Helm charts: Gateway API HTTP-to-HTTPS redirect status code is hardcoded to 302 and cannot be disabled",
      "status": "Backlog",
      "description_text": "Problem Two coupled gaps mean a tenant on Gateway API cannot control HTTP-to-HTTPS redirect behavior at all. 1. The auto-generated redirect route hardcodes 302. mozcloud-gateway/library/templates/_httproute.yaml:137-140  emits: - type: RequestRedirect\n        requestRedirect:\n          scheme: https\n          statusCode: 302 The library does define a configurable default ( mozcloud-gateway-lib.defaults.httpRoute.config  sets  redirect.statusCode: 302 ,  _helpers.tpl:451-453 ), but the HTTP-to-HTTPS route never reads it. 2. User-defined redirect filters are unreachable from the application chart. The library supports  rules[].redirect  including  statusCode  ( _httproute.yaml:88-99 ), but  mozcloud/application/values.schema.json  defines  httpRoutes.rules[]  with  additionalProperties: false  and only  backendRefs  +  matches .  rules[].redirect  is therefore rejected by schema validation, so there is no values-level workaround. There is also no way to disable the redirect per host.  httpToHttpsRedirect: false  is set only for  type: internal  ( templates/gateway/httproute.yaml:80 ) or per- gatewayRef  when using  sharedGateway . By contrast, the Ingress path exposes this fully via  hosts.<host>.frontendConfig.redirectToHttps.{enabled, responseCodeName} , with an enum of  MOVED_PERMANENTLY_DEFAULT | FOUND | SEE_OTHER | TEMPORARY_REDIRECT | PERMANENT_REDIRECT . Migrating a host from Ingress to Gateway API therefore changes its redirect semantics silently. Impact This is a behavior regression for any tenant migrating off GKE Ingress. FxA's shared  FrontendConfig  sets  redirectToHttps.responseCodeName: MOVED_PERMANENTLY_DEFAULT  ( 301 ) for all four of its Ingresses. Moving those hosts to the MozCloud chart's Gateway path would change the redirect to  302 , which is user-visible and is cached differently by clients and by Fastly. For the FxA Ingress to Gateway API migration (MZCLD-3567) we are working around this by hand-rolling a 301 redirect HTTPRoute in FxA's bespoke chart. That is exactly the kind of per-tenant divergence the shared chart is meant to eliminate, so it needs resolving before MZCLD-2323. Proposed approach Add  hosts.<host>.options.httpsRedirect.{enabled, statusCode}  to  values.schema.json  \u2014 or mirror the existing  frontendConfig.redirectToHttps  shape for symmetry, scoped to  api: gateway . Have  _httproute.yaml  read the configured status code for the auto-generated  -http-redirect  route instead of hardcoding 302. Decide the default deliberately (301 matches GKE Ingress behavior; 302 matches current chart behavior). Allow  enabled: false  per host so the redirect route can be suppressed without abusing  type: internal . Separately, consider widening  httpRoutes.rules[]  to expose the library's  redirect  and  rewrite  filters, since  additionalProperties: false  currently blocks both and there is no escape hatch. Related:  MZCLD-3638 (non-functional internal host type), MZCLD-3773 (health check protocol hardcoded to HTTP), MZCLD-2323 (FxA MozCloud chart migration), MZCLD-3567 (FxA Ingress to Gateway API migration).",
      "comment_count": 0,
      "comments": []
    }
  }
]

usage

{
  "model": "claude-sonnet-5",
  "input_tokens": 4360,
  "output_tokens": 2106,
  "estimated_cost_usd": 0.04467
}

approvals

[]

log

launched k8s job run-run-3b038b37e51906b3 in ns/mzcld-demo-dev image=us-docker.pkg.dev/moz-fx-mzcld-demo-prod/mzcld-demo-prod/agentplat:latest
runner started
live reasoning model=claude-sonnet-5