fluent/fluentd · error

BUG: #{msg}

Error message

BUG: #{msg}

What it means

ServiceDiscovery::Manager#run_once drains its queue of discovery events; every element is expected to be a Fluent::Plugin::ServiceDiscovery::DiscoveryMessage. If something else (string, hash, nil) was enqueued, it logs 'BUG: <msg>' and skips it — an internal invariant violation, since only Fluentd code and custom discovery plugins should push into that queue via the documented send_message path.

Source

Thrown at lib/fluent/plugin_helper/service_discovery/manager.rb:89

            @discoveries.each do |d|
              d.__send__(mth)
            end
          end
        end

        def run_once
          # Don't care race in this loop intentionally
          s = @queue.size

          if s == 0
            return
          end

          s.times do
            msg = @queue.pop

            unless msg.is_a?(Fluent::Plugin::ServiceDiscovery::DiscoveryMessage)
              @log.warn("BUG: #{msg}")
              next
            end

            begin
              handle_message(msg)
            rescue => e
              @log.error(e)
            end
          end

          rebalance
        end

        def rebalance
          @load_balancer.rebalance(services)
        end

        def select_service(&block)

View on GitHub (pinned to dd45c6e18d)

Solutions

  1. Audit custom service_discovery plugins: enqueue only via the documented API that wraps payloads in ServiceDiscovery::DiscoveryMessage.
  2. Report upstream with the logged payload, plugin list, and full backtrace — stock Fluentd cannot enqueue foreign objects.
  3. Reproduce with third-party discovery plugins disabled to isolate which component pushes invalid messages.
  4. Upgrade to the latest Fluentd patch release.
Defensive patterns

Strategy: type-guard

Type guard

# Only ever enqueue DiscoveryMessage-wrapped events into the discovery manager
Fluent::Plugin::ServiceDiscovery::DiscoveryMessage === msg || raise(ArgumentError, 'discovery queue accepts DiscoveryMessage only')

Prevention

When it happens

Trigger: A custom service_discovery plugin pushing raw objects into the manager's queue instead of building DiscoveryMessage instances; thread-unsafe or experimental monkeypatches around the discovery manager; a Fluentd bug in a specific version's discovery plumbing.

Common situations: Writing a bespoke discovery mechanism (consul/etcd-style) as a Fluentd plugin and bypassing the message API; forked Fluentd versions drifting from upstream queue handling.

Related errors


AI-assisted analysis of fluent/fluentd@dd45c6e18d (2026-08-21). Data as JSON: /api/errors/9d4f286925d74fb1. Report an issue: GitHub.