Persistent queue event ordering constraints during rolling node migrations

Migrating a small Logstash application without downtime typically requires utilizing persistent queues to buffer incoming data during a rolling update. While setting queue.type: persistent ensures that events are written to disk and survive restarts, the behavior under high concurrency remains complex.

n

When multiple worker threads are configured to process a single persistent queue, Logstash handles events asynchronously to maximize throughput. In a migration scenario where nodes are drained and restarted with updated configurations, there is uncertainty regarding whether the original sequence of events is maintained as they reach the output plugin.

n

Does Logstash guarantee strict FIFO ordering when multiple workers are pulling from the same persistent queue? Is there a configuration to to enforce sequential processing without reverting to a single-threaded execution model during the migration window?