Upgrade `concurrent-ruby` dependency.

[mashhurs]

Claude generated content

Summary: blocker for upgrading concurrent-ruby in logstash-core

Situation

logstash-core.gemspec pins concurrent-ruby to "~> 1", "< 1.1.10", with a comment referencing this issue. The latest release is 1.3.7, so the pin holds Logstash several minor versions behind. Because the vast majority of plugins pull concurrent-ruby transitively through logstash-core (and a few through logstash-codec-multiline, jls-lumberjack, or jruby-jms), no plugin pins it directly — the constraint lives entirely in logstash-core. Lifting it here unblocks the whole dependency tree.

A secondary consequence: the gemspec also pins multi_json to "~> 1.19.1" specifically because multi_json 1.20.0 (java) requires concurrent-ruby ~> 1.2. Both pins are coupled and would be lifted together.

Breaking change

Starting in concurrent-ruby 1.1.10, TimerTask timeout support was removed (originally over unsafe Thread#raise/kill and thread-leak concerns). timeout_interval is now a no-op stub — both the getter and setter, and the constructor option, only emit a warning and do nothing:

def timeout_interval
  warn 'TimerTask timeouts are now ignored as these were not able to be implemented correctly'
end

def timeout_interval=(value)
  warn 'TimerTask timeouts are now ignored as these were not able to be implemented correctly'
end

(source: lib/concurrent-ruby/concurrent/timer_task.rb on master)

This is warning-only — nothing raises or crashes. There is no deprecation notice indicating the method will be removed; it appears to be a permanent no-op.

Logstash passes timeout_interval in two places:

• x-pack/lib/monitoring/inputs/metrics.rb — :timeout_interval => @collection_timeout_interval passed to TimerTask.new
• logstash-core/lib/logstash/instrument/periodic_poller/base.rb — @task.timeout_interval = @options[:polling_timeout] (line per original report; should be re-verified against current main)

So upgrading today produces repeated startup warnings to stdout (as this issue originally reported) and silently drops the timeout enforcement these two callsites relied on — runaway metric-collection / periodic-poller tasks would no longer be force-stopped. That behavioral regression, not a crash, is the real blocker.

Resolution options

1. Remove the dead options and accept no timeout. Drop timeout_interval from both callsites; deprecate/remove the user-facing collection_timeout_interval and polling_timeout settings. Simplest, but loses the safety net entirely.
2. Reimplement the timeout in Logstash. Wrap the polled work with an explicit timeout mechanism (e.g. Timeout.timeout, or a Concurrent::Future / ScheduledTask with cancellation) so the timeout semantics are preserved without depending on TimerTask. Preserves behavior; more work.
3. Keep options as no-ops with a deprecation path. Leave the settings accepted but documented as ineffective, suppress the upstream warning, and plan removal later. Lets the upgrade proceed quickly while signalling intent.

In all three cases, the multi_json pin to ~> 1.19.1 is lifted alongside (to >= 1.20.0), and the gemspec constraint becomes something like "~> 1.3".

Open question

Is this issue still the right tracking item, or has any of the above already landed on main? The current state of the two callsites and whether a fix PR exists should be verified before picking an option.

References

• gemspec pin: https://github.com/elastic/logstash/blob/main/logstash-core/logstash-core.gemspec
• metrics.rb callsite: https://github.com/elastic/logstash/blob/main/x-pack/lib/monitoring/inputs/metrics.rb
• TimerTask source: https://github.com/ruby-concurrency/concurrent-ruby/blob/master/lib/concurrent-ruby/concurrent/timer_task.rb
• TimerTask spec (setter warns to stderr): https://github.com/ruby-concurrency/concurrent-ruby/blob/master/spec/concurrent/timer_task_spec.rb
• upstream PR removing timeout behavior: Remove timeout from TimerTask ruby-concurrency/concurrent-ruby#926
• concurrent-ruby versions: https://rubygems.org/gems/concurrent-ruby/versions