fix: use the null-guarded metrics field in the Controller constructor

[csviri]

The constructor deliberately guards against a null Metrics:

this.metrics = Optional.ofNullable(configurationService.getMetrics()).orElse(Metrics.NOOP);

but its last statement bypasses that guard and calls the getter again:

configurationService.getMetrics().controllerRegistered(this);

so a ConfigurationService whose getMetrics() returns null fails with a
NullPointerException during controller construction, which is exactly what
the guard three lines up is meant to prevent. EventProcessor applies the
same != null ? metrics : Metrics.NOOP guard, so the codebase does treat
a null Metrics as reachable even though the interface default returns
Metrics.NOOP.

Uses the already-resolved metrics field instead.

Part of #3517

[Copilot]

Pull request overview

Fixes a controller-construction correctness bug in operator-framework-core where the constructor would bypass the null-guarded metrics field and re-fetch Metrics from ConfigurationService, causing a potential NullPointerException when getMetrics() returns null.

Changes:

• Use the already null-guarded metrics field to call controllerRegistered(this) instead of calling configurationService.getMetrics() again.

[csviri]

LGTM

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/Controller.java:141

• Consider adding a regression unit test covering the original failure mode: a ConfigurationService implementation whose getMetrics() returns null should not throw during Controller construction (and should behave as if Metrics.NOOP was used). There are existing Controller tests in this module, but none exercise the null-metrics path.

    metrics.controllerRegistered(this);