openfaas/faas · error

unknown log request error (%v)

Error message

unknown log request error (%v)

What it means

After forwarding a log request to the provider, the handler in gateway/handlers/logs.go switches on the response status: 200 streams log output, and 404/501 map to 501 Not Implemented (provider has no log API). Any other status falls into the default branch and is returned as 500 with 'unknown log request error (CODE)'. The provider's original status code is embedded in the message, so it tells you exactly what came back.

Source

Thrown at gateway/handlers/logs.go:88

		switch logResp.StatusCode {
		case http.StatusNotFound, http.StatusNotImplemented:
			w.WriteHeader(http.StatusNotImplemented)
			return
		case http.StatusOK:
			// watch for connection closures and stream data
			// connections and contexts should have cancel methods deferred already
			select {
			case err := <-copyNotify(&unbufferedWriter{wf}, logResp.Body):
				if err != nil {
					log.Printf("LogProxy: error while copy: %s", err.Error())
					return
				}
			case <-cn.CloseNotify():
				log.Printf("LogProxy: client connection closed")
				return
			}
		default:
			http.Error(w, fmt.Sprintf("unknown log request error (%v)", logResp.StatusCode), http.StatusInternalServerError)
		}

		return
	}
}

type writerFlusher interface {
	io.Writer
	http.Flusher
}

// unbufferedWriter is an io Writer that immediately flushes the after every call to Write.
// This can wrap any http.ResponseWriter that also implements Flusher.  This ensures that log
// lines are immediately sent to the client
type unbufferedWriter struct {
	dst writerFlusher
}

View on GitHub (pinned to 8d803bf9e2)

Solutions

1. Read the status code in parentheses of the error body — it is the provider's actual response code
2. Inspect the provider logs for the failing /system/logs request
3. If the code is 401/403, align auth credentials between gateway and provider
4. If 502/503, check any load balancer or service mesh between the components
5. Confirm the provider version implements container logs — 404/501 are handled gracefully, other codes are not

# expect 200, 404 or 501; anything else indicates misconfiguration
status=$(curl -s -o /dev/null -w '%{http_code}' "$PROVIDER/system/logs?name=$FN")
case "$status" in
  200|404|501) ;;
  *) echo "unexpected provider status $status" ;;
esac

When it happens

Trigger: The provider replies to /system/logs with an unexpected status: 500 from an internal error, 401/403 when auth (basic auth, mTLS) rejects the gateway, 429 under throttling, or 502/503 from a load balancer sitting between gateway and provider.

Common situations: Provider crashing while opening the log stream; auth credentials rotated on one side only; an ingress/LB returning 503 during health-check failures; provider versions that implement the endpoint but error for the requested function.

Related errors

• log request failed
• string(upstreamBody)
• A body is required for this endpoint
• err.Error()
• Unable to parse list of functions from provider

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