fix(flagd): validate FLAGD_SYNC_PORT before parse to avoid kubelet service-link collision

[jabenedicic]

Closes #1797

Summary

FlagdOptions.prebuild() parses FLAGD_SYNC_PORT directly with Integer.parseInt when FLAGD_RESOLVER=in-process. When a Service named flagd-sync shares the pod's namespace (the exact topology produced by the upstream flagd Helm chart and the OpenFeature Operator's InProcessConfiguration pattern), kubelet's service-link env injection populates the workload with FLAGD_SYNC_PORT=tcp://<clusterIP>:<port>, the SDK calls Integer.parseInt("tcp://..."), and the consumer crashes at startup with NumberFormatException.

Full repro, affected versions, and root-cause analysis in #1797.

Change

Validate that FLAGD_SYNC_PORT parses as an integer in [1, 65535] before using it. On invalid input, log at WARN with a pointer to the most likely cause (service-link injection) and fall back to FLAGD_PORT. Behaviour for valid, user-set FLAGD_SYNC_PORT is unchanged.

// Before
String portValue = resolverType == Config.Resolver.IN_PROCESS
        ? fallBackToEnvOrDefault(Config.SYNC_PORT_ENV_VAR_NAME, fromPortEnv)
        : fromPortEnv;
port = Integer.parseInt(portValue);

// After (sketch — see diff for full code)
String portValue = fromPortEnv;
if (resolverType == Config.Resolver.IN_PROCESS) {
    String syncPortValue = fallBackToEnvOrDefault(Config.SYNC_PORT_ENV_VAR_NAME, null);
    if (syncPortValue != null) {
        if (isValidPort(syncPortValue)) {
            portValue = syncPortValue;
        } else {
            log.warn("Ignoring {} value '{}' (not a valid port); falling back to {} ('{}'). ...",
                    Config.SYNC_PORT_ENV_VAR_NAME, syncPortValue,
                    Config.PORT_ENV_VAR_NAME, fromPortEnv);
        }
    }
}
port = Integer.parseInt(portValue);

Why this is the minimal change

The narrower fix (validation only) was preferred over alternatives:

• Stop reading FLAGD_SYNC_PORT entirely. Would match Node/Go SDK behaviour and avoid the env-var name reservation issue, but is a behaviour change for users who legitimately set FLAGD_SYNC_PORT after feat: Add FLAGD_SYNC_PORT support for in-process providers with backwards compatibility #1651. Worth discussing separately.
• Rename the env var. Cleanest but breaking; needs deprecation path.

Validation is fully backwards-compatible: legitimately set FLAGD_SYNC_PORT=NNNN continues to take precedence over FLAGD_PORT exactly as today.

Tests

Three new cases in FlagdOptionsTest, all using the existing @SetEnvironmentVariable pattern:

• testInProcessProvider_invalidSyncPortFallsBackToFlagdPort — FLAGD_SYNC_PORT=tcp://10.0.0.1:8015 + FLAGD_PORT=8888 → port 8888 (the exact service-link injection scenario).
• testInProcessProvider_invalidSyncPortWithNoFlagdPortUsesDefault — invalid FLAGD_SYNC_PORT, no FLAGD_PORT → DEFAULT_IN_PROCESS_PORT.
• testInProcessProvider_outOfRangeSyncPortFallsBackToFlagdPort — FLAGD_SYNC_PORT=99999 → falls back (port out of valid range).

Existing tests for FLAGD_SYNC_PORT precedence and fallback are unchanged and continue to pass. Full suite: 21 tests, 0 failures, 0 errors.

mvn spotless:apply reports no formatting changes required.

Out of scope

• Whether the SDK should read FLAGD_SYNC_PORT at all (cross-language alignment / env-var name reservation discussion) — flagged in flagd-provider-java reads FLAGD_SYNC_PORT in in-process mode, colliding with Kubernetes service-link env injection #1797 for a separate conversation.

[gemini-code-assist]

Code Review

This pull request enhances the flagd provider's configuration logic by introducing validation for the FLAGD_SYNC_PORT environment variable. This change prevents the provider from crashing when encountering non-numeric values, such as those injected by Kubernetes service-links, by logging a warning and falling back to the standard port or default value. The feedback suggests adding a final safety check using the new validation method before the final integer parsing to ensure the provider remains stable even if the fallback port configuration is also invalid.

[chrfwow]

Do we need this alias?

[jabenedicic]

Yes — portValue and fromPortEnv are intentionally distinct:

• portValue is the mutable "chosen port" — it gets reassigned to syncPortValue on the valid-FLAGD_SYNC_PORT path (line 324) and to defaultPort on the final invalid-port fallback (line 355).
• fromPortEnv is the stable original FLAGD_PORT value, still referenced in the WARN log on line 340 so the operator can see the exact fallback value being chosen.

Collapsing them would either lose that detail from the log message or require recomputing/getenv-ing it a second time. Happy to rename portValue → chosenPort if that makes the intent clearer, but I'd prefer to keep the two variables distinct.