improv(metrics): consistent duplicate dimension handling

[uttam282005]

Summary

This PR restores and improves the warning mechanism for overwritten default dimensions in the Metrics utility:

Changes

• Restores the warning logic that was unintentionally removed in a prior revert.
• Fixes a bug where calling captureColdStartMetric() would emit duplicate warnings for the service dimension.
• Refines warning behavior to only trigger when the overwritten service dimension is different from the internal default (i.e., truly user-defined).

---

Additional Fix

Previously, passing defaultDimensions with a service key in the constructor triggered unnecessary warnings, beacause service was set internally as a default dimension via setService():

new Metrics({
  defaultDimensions: {
    service: 'auth-service', // <-- warning was wrongly emitted 
  },
});

Now, this behavior is handled correctly. No warning is emitted if the service in defaultDimensions is the same as the internal default service name.

---

Final Fix Summary

• Avoids redundant call to setDefaultDimensions() inside captureColdStartMetric(), which previously caused a second warning.
• Prevents unnecessary or duplicate warnings when instantiating Metrics with service value in defaultDimensions.

Issue number: #4134

---

Note

Instantiating the object like this will still emit a warning as user is trying to overwrite previously passed serviceName, even if they are equal. This behaviour is consistent with other methods like addDimensions and addDimension.

const metrics = new Metrics({
  serviceName: 'some-service',
  defaultDimensions: {
    service: 'some-service', // ⚠️ Warning: service already added
  },
});

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sdangol]

@uttam282005 I tried to run the e2e tests against the PR, and one of the tests is failing. It seems like there's still one warning that gets logged if we use captureColdStartMetric.
I'm not sure, but I think it has to do with this.defaultServiceName. We're doing this in setService to get the service, do we need something similar?

service ||
this.getCustomConfigService()?.getServiceName() ||
this.#envConfig.serviceName ||
this.defaultServiceName;

[uttam282005]

I believe the warning occurs because the service dimension is initially set via setService(), this value can come from a user-provided serviceName, an environment variable, or a custom config service. Later, when setDefaultDimensions() is called (and includes a service key), we get a warning indicating the service dimension is being overwritten.

In many cases, this warning is correct, it's a user attempting to override a previously set user-defined service value, which we want to surface. However, the problem arises when setDefaultDimensions() is called internally (e.g., within captureColdStartMetric() or during initialization like singleMetric() ). In these cases, the overwrite is intentional and should not trigger a warning.

To address this, the cleanest solution I can think of is introducing a private boolean flag that marks such internal calls. This flag would let us suppress the warning when setDefaultDimensions() is invoked by internal logic rather than user input, preserving the intent of the warning without polluting logs in expected flows.

[uttam282005]

The root cause is the call to single metric which is emitting the same behaviour that I have written in the note section of the PR.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dreamorosi]

Why were these two removed and extracted in the constructor?

[uttam282005]

setEnvConfig() and setConsole() calls from setOptions() were moved to the constructor to ensure logger is initialized before any method (eg. setDefaultDimensions) uses it.

[uttam282005]

@dreamorosi @sdangol I’d like to get your thoughts on how best to solve this.

[sdangol]

@uttam282005 I think having the flag to maintain the internal calls would probably add some complexity to this. Let me think this through for some more time, discuss with the team and get back to you

[uttam282005]

private static supressWarnings = false;

private static supressSetDefaultDimensionsWarnings<T>(fn: () => T): T {
  Metrics.supressWarnings = true;
  try {
    return fn();
  } finally {
    Metrics.supressWarnings = false;
  }
}

How is this approach?