David Ashpole

My notes from the Spec SIG meeting: * We want users to be able to try out experimental features. * We want experimental feature prototypes to be discoverable, and somehow...

From our meeting today: Consensus: experimental SDK interfaces on stable modules should: * Expose types in a new module. This module is not tagged. * SDK uses reflection to access...

We should try to create a simpler reproduction (not using the collector) to make this easier to root-cause

@pree-dew feel free to work on this. It is likely going to be tricky to root-cause, but any help is appreciated

Aggregations for each reader should be isolated from each other. A meter has a single resolver for int64: https://github.com/open-telemetry/opentelemetry-go/blob/1a964cc449d302a787c2a80a02a3731af12ab981/sdk/metric/meter.go#L59 The resolver has a list of pipelines: https://github.com/open-telemetry/opentelemetry-go/blob/1a964cc449d302a787c2a80a02a3731af12ab981/sdk/metric/pipeline.go#L600-L604 There is one...

Added some printing in the sum aggregation: ``` measure s: 0xc0000aa740, v.n += value: 0 += 1 measure s: 0xc0000aa760, v.n += value: 0 += 1 cumulative s: 0xc0000cb830, i:...

I did some more digging. The issue is that the Instrument we return to users from `Int64ObservableCounter` contains the measure functions for that instrument from all pipelines (readers). Here, we...

I actually fixed a very similar bug if callbacks were registered using WithCallback() in https://github.com/open-telemetry/opentelemetry-go/pull/4742

To fix it, we need to ensure that only callbacks associated with the pipeline are called during the pipeline's `Collect()` function. In https://github.com/open-telemetry/opentelemetry-go/pull/4742 this was done by passing an instrument...

It is probably easiest if observer has a reference to its pipeline, and the map[observableID]measure is on the pipeline. We probably need to leave appendMeasure alone for now, since the...