Tyler Yahn

The timestamp arg is something recommended by the specification: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#exemplarreservoir This may be necessary now, but when we accept a user defined reservoir this seems like an important parameter. Would...

> We should probably have one Offer to the (non-public) FilteredReservoir which does not have a timestamp argument, and one Offer to the (to-be-public) Reservoir which does have the timestamp...

Please provide the example code that you used to generate that graphic. I mean not aware of a function in this project called `AddTagToContext`. It looks like an inlining to...

Implementation PoC looks good. The performance impact is going to be sever, as you mention. Ideally we don't go in this direction. Another thing not included, the `Record` cannot be...

> I added a following comment for `Processor.Emit`: > > > Implementations must not modify the record after OnEmit returns. Commenting something like this is not going to be a...

> I think the solution could be adding a `sync.Mutex` to `Record` and then we would need to always use `*Record` instead of `Record`, right? If we want to go...

> > Additional to users use-case, we by default provide a batch processor. What happens when an processor modifies a record it was passed to a batch processor? > >...

> I think that only making the log record concurrent safe will get rid of this problem. I am afraid of the performance consequences of adding a sync.Mutex to each...

Waiting to merge so @XSAM can review.

Looks like `go mod tidy` needs to be run.