LogRecord#attributes= setter does not update @total_recorded_attributes

[ltickett]

Description of the bug

When mutating a LogRecord's attributes after initialization (e.g. in a custom LogRecordProcessor#on_emit), the attributes= setter updates the attributes hash but does not recalculate @total_recorded_attributes. This means to_log_record_data reports a stale count from initialization time.

There is no public API to update @total_recorded_attributes — the only workaround is instance_variable_set(:@total_recorded_attributes, attrs.size), which is fragile and depends on SDK internals.

Expected behavior: Either attributes= should automatically update @total_recorded_attributes, or a public method should be provided to recalculate it.

Relevant code: logs/lib/opentelemetry/sdk/logs/log_record.rb (https://github.com/open-telemetry/opentelemetry-ruby/blob/main/logs_sdk/lib/opentelemetry/sdk/logs/log_record.rb) — @total_recorded_attributes is set once in initialize and never updated when attributes is reassigned via the attr_accessor.

Here's the merge request/project where I encountered this issue: https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/merge_requests/2325

Share details about your runtime

• Operating system details: Linux, Debian 12 (bookworm), aarch64
• RUBY_ENGINE: "ruby"
• RUBY_VERSION: "4.0.5"
• RUBY_DESCRIPTION: "ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM aarch64-linux"

Share a simplified reproduction if possible

require 'bundler/inline'

gemfile(true) do
  source 'https://rubygems.org'

  gem 'opentelemetry-api'
  gem 'opentelemetry-sdk'
  gem 'opentelemetry-logs-sdk'
end

require 'opentelemetry-api'
require 'opentelemetry-sdk'
require 'opentelemetry/sdk/logs'

log_record = OpenTelemetry::SDK::Logs::LogRecord.new(
  body: 'test message',
  attributes: { 'key1' => 'value1' }
)

puts "Initial attributes count: #{log_record.instance_variable_get(:@total_recorded_attributes)}"
# => 1

log_record.attributes = { 'key1' => 'value1', 'key2' => 'value2', 'key3' => 'value3' }

puts "Attributes after reassignment: #{log_record.attributes.size}"
# => 3
puts "total_recorded_attributes (stale): #{log_record.instance_variable_get(:@total_recorded_attributes)}"
# => 1 (BUG: should be 3)

data = log_record.to_log_record_data
puts "Reported in log_record_data: #{data.total_recorded_attributes}"
# => 1 (stale)

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[ltickett]

I'm happy to try and push a fix if y'all are in agreement this is indeed a valid issue and should be fixed

It may be that there's a better approach to do what i'm trying to do (injecting attributes)

Thanks

[thompson-tomo]

Thanks for reporting this and i would agree it does look like an issue. In fact on looking at the code there does also appear to be atleast 1 additional issue which is that the log limits are only enforced at log record creation time hence a processor can exceed these limits.

In relation to your issue and after consulting the proto/spec, my suggestion would be we remove the attribute count from the log record and instead have a dropped attribute count which is what the exporters require.

Reason for this approach would be if u have a limit of 5 attributes but add 6, the total would be 6. If the processor then adds 3 new attributes & removes 1 attribute. What should the total be? For me It would currently have to be 9 so that the dropped can be calculated. However having the total differing to size feels strange especially as we only need to know dropped.

Keen to hear others thoughts though.

As a side note, have you considered implementing your enrichment using a collector which is the suggested approach.

[ltickett]

Super, thanks @thompson-tomo - do you need me to do anything, or are there some discussions required amongst maintainers to figure out exactly what the path forward looks like?

I could always throw up a small PR to fix this the way I had in mind then we could iterate once we have a more solid path forward?

With regard to:

As a side note, have you considered implementing your enrichment using a collector which is the suggested approach.

I don't really understand how this would work. Do you have any more details?

My understanding is that the collector only has access to the data we send it, so we need to enrich the data at source (the app).

How would the collector be able to gather this additional data if we don't inject it from within our app in the first place?

[thompson-tomo]

Lets hold off on pr until further discussion especially in light of my findings.

My understanding is that the collector only has access to the data we send it, so we need to enrich the data at source (the app).

It has access to the data it recieved but it can fetch additional information see https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.154.0/processor/lookupprocessor, https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.154.0/processor/attributesprocessor or https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/v0.154.0/processor/geoipprocessor as an example