-
Notifications
You must be signed in to change notification settings - Fork 893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define data ownership for LogRecordProcessor #2969
Define data ownership for LogRecordProcessor #2969
Conversation
We haven't concluded the discussion last time. What are we aiming for here? Chained processors? |
The approach with this PR is to try to resolve the mutability question while maintaining a LogRecordProcessor design as similar as possible to SpanProcessors: LogRecordProcessors are called by the SDK LoggerProvider in the order they were provided. There is no responsibility for a processor to call the next processor (i.e. no chaining). It's not the only approach, but should be a frontrunner in my opinion since its simple to implement, consistent with tracing, and is quite flexible. |
@open-telemetry/specs-logs-approvers please take a look. |
Resolves #2955.
States that
LogRecordProcessor#onEmit
can modifylogRecord
until it returns. If a reference tologRecord
is held afteronEmit
returns, only reads are permitted.If a processor wants to do asynchronous modification it needs to first make a copy is responsible for calling any downstream processors / exporters that expect to see the changes. Described more here.