Audit Compliance: Logs SDK ReadableLogRecord

[pellared]

1. Review the ReadableLogRecord section of the Logs SDK specification for all Stable normative statements.
2. Audit the logs SDK package for compliance with the specified Stable normative statements.
3. Do not include any statements or sections marked Status: Development in this audit.
4. Identify existing issues or create new issues to track any work needed to make the logs SDK package compliant with the Stable specification.

This is a fresh open audit for the current main specification. A previous audit issue was closed: #5684.

[pellared]

Verdict

NONCOMPLIANT under the natural reading of the dropped-attribute-count MUST. The readable record surface exposes the required record, Scope, Resource, resolved trace context, and dropped-attribute count. However, exception attributes omitted specifically because the configured attribute-count limit has no remaining capacity are not included in DroppedAttributes.

Focused bug #8791 tracks this accounting defect and the associated specification interpretation. Audit issue #8547 can close after this audit is posted and cross-linked.

Scope

• Implementation: 0de413a3.
• Stable ReadableLogRecord requirements: sdk.md at 041241bf.

The Stable specification requires a function receiving a ReadableLogRecord to access all LogRecord information, its associated Instrumentation Scope and Resource, trace context resolved at emission, and counts for attributes dropped due to collection limits so exporters can report them (ReadableLogRecord).

Compliant readable surface

• Event name, timestamps, severity, body, and attributes are readable through typed getters and WalkAttributes (sdk/log/record.go).
• DroppedAttributes, TraceID, SpanID, trace flags, Resource, and Instrumentation Scope are exposed (sdk/log/record.go).
• Trace context is populated from the resolved Go context when the record is emitted (sdk/log/logger.go).
• Ordinary count-limit drops, including drops caused by a zero limit, call addDropped and are reflected by DroppedAttributes (addDropped, AddAttributes).

Exception-derived attributes are undercounted

When a record contains an exception, the SDK derives missing exception.message and exception.type attributes by default. The exception path first computes the remaining attribute capacity. If another derived attribute cannot fit, execution jumps to flush; only attributes that fit are appended through addAttrs, and the code never calls addDropped for the exception attributes omitted because capacity was exhausted (sdk/log/logger.go).

The existing tests demonstrate the result. The error fixture contains two caller-provided attributes and an error from which message and type can be derived (fixture). With the attribute-count limit configured to zero, the expected record reports dropped: 2, counting only the two caller-provided attributes (option path, environment path). The two exception-derived attributes omitted because of the same limit are not included. Under the natural reading of the requirement, the count should be four: two dropped caller attributes plus two omitted exception-derived attributes.

Specification interpretation

The Logs SDK specification permits implementations to consider configured attribute limits while generating exception attributes, especially large values such as exception.stacktrace (exception generation note). This permits avoiding unnecessary construction work, but it does not explicitly say whether an attribute skipped before materialization must be included in the dropped count.

The natural reading of “counts for attributes due to collection limits” is that a known, derivable attribute omitted because the limit has no capacity is an attribute dropped due to a collection limit. The implementation already establishes that the limit is the reason generation stops. Avoiding allocation or value construction need not erase the accounting consequence of that decision.

If the intended interpretation is instead that an exception attribute never materialized is not “dropped,” the implementation can be considered compliant, but that interpretation should be explicitly recorded in #8791 because it is not clear from the current specification text.