flagd-provider-java reads FLAGD_SYNC_PORT in in-process mode, colliding with Kubernetes service-link env injection

[jabenedicic]

Summary

FlagdOptions.prebuild() (introduced in #1651, released in dev.openfeature.contrib.providers.flagd v0.11.19) reads FLAGD_SYNC_PORT first when FLAGD_RESOLVER=in-process, falling back to FLAGD_PORT only when FLAGD_SYNC_PORT is unset. The value is passed to Integer.parseInt without validation.

When the SDK is used in a Kubernetes pod and a Service named flagd-sync exists in the same namespace, kubelet's service-link environment variable injection populates the workload container with FLAGD_SYNC_PORT=tcp://<clusterIP>:<port>. The SDK then crashes at startup with:

java.lang.NumberFormatException: For input string: "tcp://172.20.136.125:8015"
	at java.base/java.lang.Integer.parseInt(Integer.java:662)
	at dev.openfeature.contrib.providers.flagd.FlagdOptions$FlagdOptionsBuilder.prebuild(FlagdOptions.java:321)
	at dev.openfeature.contrib.providers.flagd.FlagdProvider.<init>(FlagdProvider.java:71)

This affects every JVM consumer using FLAGD_RESOLVER=in-process when deployed alongside the upstream flagd Helm chart or via the OpenFeature Operator's InProcessConfiguration pattern — i.e. the documented happy-path deployment topologies.

Reproduction

1. Deploy flagd in namespace N using the upstream flagd Helm chart (creates Service/flagd-sync on port 8015).
2. Deploy a JVM workload in namespace N with FLAGD_RESOLVER=in-process, FLAGD_HOST=flagd-sync.N.svc.cluster.local, FLAGD_PORT=8015, and enableServiceLinks: true (the default).
3. Start the workload.

Expected: provider initializes against flagd-sync:8015.
Actual: NumberFormatException from FlagdOptions$FlagdOptionsBuilder.prebuild because kubelet has populated FLAGD_SYNC_PORT with the Service's URL before the SDK reads it.

Affected versions

• v0.11.19 (first release after feat: Add FLAGD_SYNC_PORT support for in-process providers with backwards compatibility #1651, 2026-01-06) through v0.13.3 (current latest at filing, 2026-05-11).
• v0.11.18 and earlier read only FLAGD_PORT and are unaffected by this specific bug. (Note: v0.11.18 has a separate in-process cold-start hang fixed in v0.11.19, so rolling back is not a viable workaround.)

Why this is a bug, not a config issue

1. It collides with the upstream chart's own Service name. flagd-sync is the name produced by the flagd Helm chart and the OpenFeature Operator. The SDK is incompatible with its own deployment story.
2. The env var name is already reserved. FLAGD_SYNC_PORT is the flagd daemon's env var, derived from its --sync-port CLI flag (see the flagd Options wiki). Using it for a client-side config too creates a server/client semantic collision in any config system that sets env vars uniformly.
3. Other-language SDKs don't do this. The Node.js and Go in-process providers don't read FLAGD_SYNC_PORT at all — they read FLAGD_PORT only. PR feat: Add FLAGD_SYNC_PORT support for in-process providers with backwards compatibility #1651 was a Java-only addition not mirrored in sibling SDKs.
4. No integer validation before parse. Even setting the name issue aside, Integer.parseInt on an env var of unknown provenance is fragile; a URL-format value is a strong indicator of service-link injection, not user intent.

Suggested fix (PR forthcoming)

Validate that FLAGD_SYNC_PORT parses as an integer in [1, 65535] before using it. If it doesn't, log at WARN with a pointer to the most likely root cause (service-link injection) and fall back to FLAGD_PORT. Minimal change, backwards-compatible for users who legitimately set FLAGD_SYNC_PORT.

Longer-term considerations worth a separate discussion (not in this PR):

• Whether the SDK should read FLAGD_SYNC_PORT at all, given the name is already reserved by the flagd daemon and the JS/Go SDKs don't read it.
• Cross-language alignment in the OpenFeature spec for in-process sync port configuration.

Environment

• dev.openfeature.contrib.providers:flagd 0.11.19 — 0.13.3
• OpenFeature Java SDK 1.19.0 (any version in the provider's [1.0, 2.0) range)
• Kubernetes ≥ v1.6 (any version with service-link env injection)
• Reproduces independent of OS / JVM version / flagd server version

Workarounds

Until the SDK is fixed, affected users can:

• Set enableServiceLinks: false on JVM workload pod templates (per-pod, easy to lose on chart changes).
• Rename the upstream flagd-sync Service so its derived env var prefix doesn't match FLAGD_SYNC_* (chart values-only change if the chart exposes the name).
• Deploy flagd in a sibling namespace from JVM workloads (restores the standard cross-namespace topology, no env vars synthesized).