Reproduction for sentry-ruby yabeda-memory-growth

[dingsdax]

Summary

• Reproduces the memory growth from sentry-ruby#2963 (post-deadlock-fix)
• Discovers a bug in sentry-ruby: Scope#apply_to_telemetry mutates the caller's attributes hash in-place, which corrupts hash keys in yabeda's metric.values (Concurrent::Hash)
• Every metric increment creates a new orphaned entry — values hash grows linearly with call count instead of being bounded by unique tag combinations
• With sentry-yabeda: active_record_instantiation_total shows 2005 entries for 50 unique kinds (should be 50). RSS growth is 14x worse (+21 MB vs +1.5 MB)

Root cause

MetricEvent#initialize stores the caller's attributes hash by reference (@attributes = attributes || {}). Then Scope#apply_to_telemetry adds sentry-specific keys (sentry.sdk.name, sentry.sdk.version, sentry.environment, server.address) directly onto this hash. Since sentry-yabeda passes the same hash object that yabeda uses as a key in its values hash, the key is mutated after insertion — its hash code changes, and future lookups can never find it.

Fix: Either MetricEvent should .dup the attributes hash, or Scope#apply_to_telemetry should work on a copy.

Test plan

• Run bundle exec ruby repro.rb — yabeda-only baseline showing bounded growth
• Run SENTRY_DSN=... bundle exec ruby repro.rb — shows hash mutation proof (Part 1) and 14x worse growth (Part 2)
• Alternatively, use Docker: docker build -t yabeda-repro . && docker run --rm yabeda-repro

🤖 Generated with Claude Code