[API Proposal]: Gauge metric creation should support async callback signature

Open
#96,850 1 comment 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
csharp
Domain
api, backend-api-design

Research direction

Start with the linked Meter.CreateObservableGauge API documentation and compare the existing overload signatures with the proposed async callback shape. Then review the runtime's API design and validation conventions to determine the complete overload set and callback contract. Done means the async API design is agreed, implemented, and validated against the relevant API and behavior tests.

Written by the indexing model from the issue text.

Description

api-suggestion area-System.Diagnostics.Metric
Background and motivation

System.Diagnostics.Metrics.Meter exposes the set of CreateObservableGauge overloads, but none of them allow for safe and efficient use of threads in the callback implementation. I.e. given that most of modern IO APIs are starting to ship exclusively with Async APIs (returning Task or similar), acquiring the value for the gauge metric will mean blocking the thread in order to conform to the sync callback signature.

API Proposal

Add the overloads to support async signatures, for example:

CreateObservableGauge<T>(String, Func<Task<Measurement<T>>>, String, String, IEnumerable<KeyValuePair<String,Object>>)
API Usage
meter.CreateObservableGauge<int>("name", MyTaskReturingFunction)
Alternative Designs

Alternatives, like separating the acquisition of the metric value from the callback impl would complicate and potentially defeat the purpose of having the configurable framework that already has an internal scheduler.

Risks

No response

Dominant language
C#
Stars
18.3k
Forks
5.6k
Avg merge
2d 19h
Merged PRs (30d)
589

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.