Skip to content

minor: add getServiceDims() getter to ServiceMetricEvent#19350

Merged
abhishekrb19 merged 2 commits intoapache:masterfrom
abhishekrb19:service_dims_getter
Apr 20, 2026
Merged

minor: add getServiceDims() getter to ServiceMetricEvent#19350
abhishekrb19 merged 2 commits intoapache:masterfrom
abhishekrb19:service_dims_getter

Conversation

@abhishekrb19
Copy link
Copy Markdown
Contributor

Summary

Adds a getServiceDims() getter method to ServiceMetricEvent to provide direct access to the immutable service dimensions map. This can be used by custom extensions along with the existing getters in the class.

Motivation

Previously, callers could access individual service dimension values via getService() and getHost(), but had no way to retrieve the complete service dimensions map. This getter provides direct access to the immutable map of all service
dimensions by custom extensions.

This PR has:

  • been self-reviewed.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.

Copy link
Copy Markdown

@utafrali utafrali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The getter is functionally correct and well-tested, but returning ImmutableMap<String, String> is inconsistent with the existing getUserDims() which returns the Map interface — both fields are backed by ImmutableMap, yet the API surface is different. The return type should be Map<String, String> to keep the class API coherent.

return serviceDims.get(HOST);
}

public ImmutableMap<String, String> getServiceDims()
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return type ImmutableMap<String, String> leaks the concrete implementation, which is inconsistent with getUserDims() in the same class — that method returns Map<String, Object> even though its backing field is also an ImmutableMap. For a public API, prefer returning the interface type:

public Map<String, String> getServiceDims()
{
  return serviceDims;
}

Callers who need the immutability guarantee can check instanceof ImmutableMap or the Javadoc can document it. Returning the concrete type here makes it harder to swap the implementation later.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's a good point - thanks for calling that out!

builderEvent.toMap()
);

Assert.assertEquals("test", builderEvent.getServiceDims().get("service"));
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The string literals "service" and "host" duplicate the key constants already defined in the class (used inside getService() and getHost()). If those constants (SERVICE, HOST) are accessible from the test, use them directly to avoid silent drift if the keys ever change:

Assert.assertEquals("test", builderEvent.getServiceDims().get(ServiceMetricEvent.SERVICE));
Assert.assertEquals("localhost", builderEvent.getServiceDims().get(ServiceMetricEvent.HOST));

If the constants are private, at minimum add a comment explaining why literals are used here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“service” and “host” are documented metric dimensions. Hence, they cannot change due to backward compatibility guarantees, and this test and other existing ones that assert on the literals would catch that unlikely drift.

@abhishekrb19 abhishekrb19 merged commit 185bd2d into apache:master Apr 20, 2026
87 of 90 checks passed
@abhishekrb19 abhishekrb19 deleted the service_dims_getter branch April 20, 2026 17:15
@github-actions github-actions Bot added this to the 38.0.0 milestone Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants