Cannot test all fields of a Record

[MrAlias]

The Record has both methods to return the Resource and Scope it was created with by the SDK. However, when testing from export packages (i.e. otlploghttp) it is not possible to set these values. Therefore, it is not possible to test real data from multiple sources in an exporter.

We are going to need to export a way to construct a Record with these values or add "Set" methods for them.

This will also apply to limits and the DroppedAttributes method when #5190 merges.

[pellared]

It is possible when constructing the "full" SDK logs pipeline (logger provider and simple processor). It has been designed this way to ensure encapsulation of the data which is supposed to be set by the SDK.

Yet, I see that it can be inconvenient for testing. The same problem would be for testing custom processors.

Notice we do not want the processor to be able to modify the resource nor the scope.

[MrAlias]

It is possible when constructing the "full" SDK logs pipeline (logger provider and simple processor). It has been designed this way to ensure encapsulation of the data which is supposed to be set by the SDK.

Are you saying any external package that want to test their transforms needs to install a full SDK?

That seems less than ideal.

[MrAlias]

Notice we do not want the processor to be able to modify the resource nor the scope.

Sure, but we don't want the processor to modify anything without cloning it and they are still able to do that.

This may be a reason our API is not providing the interface we want.

[MrAlias]

It might make sense to migrate to something like NewSpanContext.

We could have a NewRecord method that accepts some kind of "RecordData" and we could have the Clone method accept the same.

[pellared]

It is possible when constructing the "full" SDK logs pipeline (logger provider and simple processor). It has been designed this way to ensure encapsulation of the data which is supposed to be set by the SDK.

Are you saying any external package that want to test their transforms needs to install a full SDK?

I say that this is the current state. Thus this issue is not a bug but an enhancement.

That seems less than ideal.

I agree.

[MrAlias]

I say that this is the current state. Thus this issue is not a bug but an enhancement.

There is a missing set of fundamental functionality with the logs SDK. This deficit is why it is classified and tagged as a bug.

Adding addition enhancing functionality is not what this issue is about. It is asking to provide functionality to make this package fundamentally usable.

[pellared]

I think we could do something similar to #5195. The name could additionaly warn that it should be used only for testing exporters and processors like TestRecordBuilder.

My other idea is providing TestRecord type which embeds *Record and have SetResource and SetInstrumenationScope methods.

[MrAlias]

My other idea is providing TestRecord type which embeds *Record and have SetResource and SetInstrumenationScope methods.

Using names of types to try and restrict use has a bad smell to it. It does not use the semantics of the Go language to make the restrictions intended. It relies on users knowing what a Test thing is for and not abusing it.

We could just as easily add methods to the Record and comment that they shouldn't be used outside of testing.

I would rather explore changes to the Record API itself to see if we can design it in way that supports the use we want to promote and allows the functionality users will need from the API.

[pellared]

Maybe it would be better to have such functionality under sdk/log/logtest. I believe that @MrAlias also mentioned this idea during the SIG meeting. I think we could do this by copying record.go and record_test.go to logtest and adding SetResource and SetInstrumentationScope (and tests) in seperate files (e.g. testrecord.go and testrecord_test.go). It is possible to convert between types that have exactly same fields. See: https://go.dev/play/p/rMq8vtYDx5O.

From: #5200 (comment)

EDIT: This technique does not work across packages if there are unexported fields. #5215

[pellared]

I unassigned myself as currently I think have no good ideas on how to follow-up

I would rather explore changes to the Record API itself to see if we can design it in way that supports the use we want to promote and allows the functionality users will need from the API.

The only idea I currently have is to expand https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md#readwritelogrecord with something more or less like:

A function receiving this as an argument MAY additionally be able to modify the following information added to the LogRecord:

• Resource
• InstrumentationScope (modification MUST apply only for the log record being processed)

However, I think it may be in conflict with open-telemetry/opentelemetry-specification#3902 (comment)

On the other hand, there is a precedence from the C++ Logs SDK

@MrAlias, thoughts?

[pellared]

The problem will be also with limits, dropped attributes, attributes deduplication. I start to feel that it is better (more trustworthy) to test custom processors and exporters using it with a logger provider created in the test.

[MrAlias]

Notes from talk with @pellared

• There is an implementation bug where a processor should get a read/write record
  • A processor currently accepts a Record in OnEmit
  • Modifications to that that accepted record are never propagated to the following processors.
  • A separate issue needs to be opened to track this non-compliance
    • Log Records passed to log processor OnEmit is non-mutable #5219
• We want to restrict what processors can set so things like the limits, resource, or scope are not modified.
• We need to be able to set all fields with the SDK
• We also need a way to get records in export testing that have all fields settable
  • Go has not way to restrict access to methods of a type or functions in a package based on imports from tests
  • Given this lack of syntaxtic restriction we need to rely on conventions and documentation as best as possible
  • We need to partition whatever solution we come up with in its own package
    • In an sdk/log/logtest package we could provide wrappers around an SDK setup and a custom processor that testing packages can call and get a set of records based on any field setting they want
    • Alternatively in an sdk/log/logtest package we could reference a common sdk/interal package has a Record definition. There would be creation functions that would return a Record directly with any field set.
      • This indirection would add complexity to the package structure and may not include all side-effects the SDK would provide.

[MrAlias]

More things blocked by not allowing a way to set a record's limits: #5230