openfaas/faas · error

Unable to parse list of functions from provider

Error message

Unable to parse list of functions from provider

What it means

In AddMetricsHandler (gateway/metrics/add_metrics.go), the wrapped list-functions handler returned 200, but json.Unmarshal of its body into []types.FunctionStatus failed, so the gateway answers 500 'Unable to parse list of functions from provider'. The upstream declared success while sending content that is not the expected JSON array — typically HTML or a differently shaped payload.

Source

Thrown at gateway/metrics/add_metrics.go:47

		defer upstreamCall.Body.Close()
		upstreamBody, _ := io.ReadAll(upstreamCall.Body)

		if recorder.Code != http.StatusOK {
			log.Printf("List functions responded with code %d, body: %s",
				recorder.Code,
				string(upstreamBody))
			http.Error(w, string(upstreamBody), recorder.Code)
			return
		}

		var functions []types.FunctionStatus

		err := json.Unmarshal(upstreamBody, &functions)
		if err != nil {
			log.Printf("Metrics upstream error: %s, value: %s", err, string(upstreamBody))

			http.Error(w, "Unable to parse list of functions from provider", http.StatusInternalServerError)
			return
		}

		// Ensure values are empty first.
		for i := range functions {
			functions[i].InvocationCount = 0
		}

		if len(functions) > 0 {

			ns := functions[0].Namespace
			q := fmt.Sprintf(`sum(gateway_function_invocation_total{function_name=~".*.%s"}) by (function_name)`, ns)
			// Restrict query results to only function names matching namespace suffix.

			results, err := prometheusQuery.Fetch(url.QueryEscape(q))
			if err != nil {
				// log the error but continue, the mixIn will correctly handle the empty results.
				log.Printf("Error querying Prometheus: %s\n", err.Error())

View on GitHub (pinned to 8d803bf9e2)

Solutions

1. Verify functions_provider_url points directly at the provider service
2. Curl the provider's /system/functions endpoint directly and confirm it returns a JSON array
3. Upgrade gateway and provider to matching current versions
4. Disable or bypass any response-rewriting middleware between gateway and provider

Example fix

# before
functions_provider_url: http://ingress.default.svc:80

# after
functions_provider_url: http://gateway.openfaas.svc:8080/

# preflight: upstream must return a JSON array for the function list
curl -fsS "$FUNCTIONS_PROVIDER_URL/system/functions" | jq -e 'type == "array"' >/dev/null \
  || echo 'upstream is not a faas-provider: metrics-enriched /system/functions will fail'

When it happens

Trigger: functions_provider_url pointing at a service that is not a faas-provider (an ingress default backend, a web server, a dashboard) that returns 200 with HTML; a proxy or service mesh rewriting the response body; severe gateway/provider version skew producing a different response shape.

Common situations: Misconfigured upstream URL after reinstalling OpenFaaS; an istio/envoy layer injecting an HTML error page; pinning mismatched gateway and provider versions.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• invalid value for max_idle_conns: %s
• invalid value for max_idle_conns_per_host: %s
• log request failed
• unknown log request error (%v)
• string(upstreamBody)

AI-assisted analysis of openfaas/faas@8d803bf9e2 (2026-08-16). Data as JSON: /api/errors/334261e2e9ec4c20. Report an issue: GitHub.