add protected constructors for metric instrumentation in Temporalio.Common namespace #431
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was changed
Added new
protected
constructors forMetricCounter
,MetricGauge
, andMetricHistogram
in theTemporalio.Common
namespace. This will allow users to supply their own implementations when passing in a customMetricMeter
on the activity environment for tests.Previously the only constructors for these classes were internal, so they were not instantiable from outside of the
Temporalio
library.Why?
Users want to be able to test their metric instrumentation within an activity using the
ActivityEnvironment
abstraction, without having to run their activities inside a fullTemporalWorker
.It's fairly common to use an in-memory exporter to validate metric data points: https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.InMemory/README.md, so users want to be able to have the ability to supply a custom metric meter hooked up to an in memory exporter to write tests validating metrics.
Checklist
Closes [Feature Request] Allow metric meters to be constructed by users for tests #430
How was this tested:
No logic was added, just an additional constructor. It would be difficult to write a test for this without creating a new test assembly where internals are not visible.
In C#, protected constructors are guaranteed to be accessible by any derived class outside of the assembly: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/accessibility-levels
I updated the section on activity testing to inform users of the presence of the
MetricMeter
on theActivityEnvironment
, to be consistent with the rest of the public properties.I can re-order the properties in this list to be alphabetical, but they currently roughly appear to be in the order as the properties appear on the ActivityExecutionContext, so placing the property at the bottom to be roughly consistent