Sam Xie

> > I think it is ok for this PR to just enable the summary feature. > > Can you please showcase what would be the output on a fork?...

> > I cannot trigger the benchmark CI on this PR, > > Cannot you do it on your fork? https://github.com/XSAM/opentelemetry-go/tree/summary-for-benchmark The summary looks like this https://github.com/XSAM/opentelemetry-go/actions/runs/9786770170/attempts/1#summary-27022201692

Close as the changes have been merged into the main branch.

> But it feels like ErroTypeOther should be the case where we want to fallback to recording an error? I don't find a way to make it return `ErrorTypeOther`. In...

More information: https://opentelemetry.io/docs/specs/otel/trace/exceptions/ (not in the semconv doc) The spec about exceptions says > An exception SHOULD be recorded as an Event on the span during which it occurred if...

Sorry for joining the discussion late. @pellared I am confused about what we should do to handle errors, especially **non-terminating errors**. Should we do nothing if we encounter an error?...

I see. So, your proposal is ```go ctx, span := tracer.Tracer(instrumentationName).Start(ctx, "example") defer span.End() err := query(ctx, db) if err != nil { span.SetAttributes(semconv.ErrorType(err)) span.SetStatus(codes.Error, err.Error()) return err } return...

> In such cases, recording retry attempts as span events via span.RecordError gives users better visibility into transient issues without prematurely ending the span. Would it be strange to say...

I don't have a plan to update the major version of MySQL yet.

Per discussion with @pellared, if the logger can have an `Enabled` method, we probably don't need an `Enabled` method for the processor, as the logger can solve the memory allocation...