exporter/collector/logs: segfault when setting `gcp.source_location` about opentelemetry-operations-go HOT 3 CLOSED

Thanks for the detailed report @quentinmit, I'll take a look

from opentelemetry-operations-go.

I think Braydon might not have enough context on this bug. I had two questions that I was hoping someone with context would answer:

• Why does this code try to parse the attribute as JSON in the first place? Presumably you could just copy the logic that's already used for the HTTP fields:
  

  opentelemetry-operations-go/exporter/collector/logs.go

  Lines 551 to 557 in 02b243a

  	var httpBytes []byte
  	switch httpRequestAttr.Type() {
  	case pcommon.ValueTypeBytes:
  	httpBytes = httpRequestAttr.Bytes().AsRaw()
  	case pcommon.ValueTypeStr, pcommon.ValueTypeMap:
  	httpBytes = []byte(httpRequestAttr.AsString())
  	}

  
  but that doesn't explain why JSON was the only supported format.

• Why does this use the gcp.source_location attribute instead of the semantic conventions for code location attributes? And if we want to fix that, what happens if both attributes are present?

from opentelemetry-operations-go.

I agree that this should check more than just bytes as part of the fix, similar to the http attrs. It looks like I had that as a todo at one point too (

We use gcp.source_location because we chose to default to gcp.* for our log entry mapping. As a guess, maybe that choice predates the code location semantic conventions or it was just an oversight. But I also agree that unifying to those conventions is the right path here.

I talked to Braydon offline about if he would take this issue, sorry for not including that context. He's done a lot of work on the logs exporter and the semantic conventions around it already. But I'm happy to help with anything too.

from opentelemetry-operations-go.