(bug) 500 Error when `/v1/allflags` is called for nil map assignment

[khash]

Observed behaviour

Panic in /v1/allflags Endpoint - nil map assignment

Environment

• go-feature-flag version: 1.46.1
• Deployment: Kubernetes (relay proxy mode)
• Image: gofeatureflag/go-feature-flag:latest

Description

The /v1/allflags endpoint triggers a panic with error "assignment to entry in nil map" when processing user requests. The panic occurs in the userRequestToUser() function at line 63 of cmd/relayproxy/controller/utils.go.

Actual Behavior

The endpoint returns:

• HTTP Status: 500 Internal Server Error
• Response body: {"message":"Internal Server Error"}

The relay proxy logs a panic with the following stack trace:

Stack Trace

[PANIC RECOVER] assignment to entry in nil map goroutine 349 [running]:
github.com/thomaspoignant/go-feature-flag/cmd/relayproxy/api.(*Server).initRoutes.Recover.RecoverWithConfig.func6.1.1()
	/home/runner/go/pkg/mod/github.com/labstack/echo/v4@v4.13.4/middleware/recover.go:99 +0x156
panic({0x38ec9e0?, 0x724c720?})
	/opt/hostedtoolcache/go/1.24.6/x64/src/runtime/panic.go:792 +0x132
github.com/thomaspoignant/go-feature-flag/cmd/relayproxy/controller.userRequestToUser(0xc000566900)
	/home/runner/work/go-feature-flag/go-feature-flag/cmd/relayproxy/controller/utils.go:63 +0x45
github.com/thomaspoignant/go-feature-flag/cmd/relayproxy/controller.evaluationContextFromRequest(0x76056d?)
	/home/runner/work/go-feature-flag/go-feature-flag/cmd/relayproxy/controller/utils.go:52 +0x47
github.com/thomaspoignant/go-feature-flag/cmd/relayproxy/controller.(*allFlags).Handler(0xc000444900, {0x4f1cce8, 0xc000a24000})
	/home/runner/work/go-feature-flag/go-feature-flag/cmd/relayproxy/controller/all_flags.go:56 +0xcc

Root Cause

The panic originates from:

• File: cmd/relayproxy/controller/utils.go
• Function: userRequestToUser()
• Line: 63
• Error: assignment to entry in nil map

This suggests that a map in the user conversion logic is not being initialized before assignment.

Call Chain

1. /v1/allflags endpoint receives request
2. allFlags.Handler() is invoked (cmd/relayproxy/controller/all_flags.go:56)
3. evaluationContextFromRequest() is called (utils.go:52)
4. userRequestToUser() is called (utils.go:63)
5. PANIC occurs when attempting to assign to nil map

Additional Context

• The relay proxy successfully loads and serves individual flags via the OFREP endpoints
• The /health endpoint returns {"initialized":true} successfully
• All feature flags load correctly from the configured retrievers (GitHub in our case)
• The panic is reproducible consistently with any user context on the /v1/allflags endpoint

Suggested Fix

The map in userRequestToUser() function needs to be initialized before attempting assignments. The fix likely involves adding a make() call to initialize the map before use, or adding a nil check before assignment.

Dependencies

Based on the stack trace:

• github.com/labstack/echo/v4@v4.13.4
• go.opentelemetry.io/contrib/instrumentation/github.com/labstack/echo/otelecho@v0.63.0
• Go version: 1.24.6

Impact

• Severity: High
• Impact: The /v1/allflags endpoint is completely non-functional
• Mitigation: OFREP endpoints can be used as a workaround for evaluating individual flags

Expected Behavior

Expected Behavior

The endpoint should return all available feature flags evaluated for the given user context.

Steps to reproduce

Steps to Reproduce

1. Deploy go-feature-flag relay proxy (version 1.46.1)
2. Configure with at least one flag set and valid API key
3. Make a POST request to /v1/allflags with a valid user context:

curl -X POST "https://<your-proxy>/v1/allflags" \
  -H "Authorization: Bearer <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"user":{"key":"test-user","email":"user@example.com"}}'

[thomaspoignant]

Hey @khash thanks for your issue, I was reviewing the code based on your issue and what I have discovered that the payload in your curl is not correct because the format of the evaluation context is not correct.

First it uses the old key user and instead of being

{"user":{"key":"test-user","email":"user@example.com"}}

it should be

{"user":{"key":"test-user","custom":{"email":"user@example.com"}}}

So I have 1 question, which provider are you using to contact the relay proxy?
I suspect an issue in one of the provider.

That being said, the problem must not crash the relay proxy and should ignore the error.

[thomaspoignant]

@khash I have open a pull request #4134 to fix the issue.
I am still very keen to know which provider are you using?

[khash]

Thank you @thomaspoignant for the comment. We found this issue when we were testing using curl. Our normal SDKs (Go and Ruby) have been ok, but I though we should raise this as it throws a 500 instead of a 400.

[thomaspoignant]

The fix will return a 200 and ignore the fields, this is ok not having any custom.

[khash]

Wouldn't 400 Bad Request be the correct standard response for this?