Title: Fluent Bit 5.0.7 Forward output intermittently nests complete Forward batches inside another Forward batch

Bug Report

Describe the bug

Fluent Bit 5.0.7 on Windows intermittently sends malformed Forward protocol messages to Fluentd 1.16.11.

Instead of placing individual [time, record] events inside the Forward entries array, Fluent Bit sometimes places complete [tag, entries] Forward batches inside another Forward batch.

Expected decoded MessagePack structure:

[
  "winlog",
  [
    [event_time, record_hash],
    [event_time, record_hash]
  ],
  options
]

Observed decoded structure:

[
  "winlog",
  [
    [
      "winlog",
      [
        [event_time, record_hash],
        [event_time, record_hash]
      ]
    ],
    [
      "winlog",
      [
        [event_time, record_hash],
        [event_time, record_hash]
      ]
    ]
  ]
]

Fluentd interprets each nested Forward batch as an event:

time   = "winlog"
record = [[event_time, record_hash], ...]

It consequently rejects the record because its top-level type is an Array:

emit transaction failed:
error_class=ArgumentError
error="record must be a Hash: Array"
tag="winlog"

This is followed by:

unexpected error on reading data
error_class=ArgumentError
error="record must be a Hash: Array"

The individual Windows records inside the nested batches are valid MessagePack maps. Arrays inside record fields, such as StringInserts, are valid and are not the source of the error.

To Reproduce

• Rubular link if applicable: N/A

• Example log message if applicable:

An anonymized individual Windows record inside one of the nested batches:

{
  "RecordNumber": 1000001,
  "TimeGenerated": "2026-07-30 13:10:01 +0300",
  "TimeWritten": "2026-07-30 13:10:01 +0300",
  "EventID": 4624,
  "EventType": "SuccessAudit",
  "Channel": "Security",
  "SourceName": "Microsoft-Windows-Security-Auditing",
  "ComputerName": "HOST01.example.invalid",
  "Message": "<redacted>",
  "StringInserts": [
    "<redacted>",
    "<redacted>"
  ]
}

An anonymized diagnostic entry showing how Fluentd interpreted one nested batch:

{
  "diagnostic_timestamp": "2026-07-30T10:20:04.133768Z",
  "sender_address": "<redacted>",
  "incoming_tag": "winlog",
  "forward_mode": "Forward",
  "chunk_id": null,
  "batch_size": 153,
  "bad_event_index": 0,
  "event_time": "\"winlog\"",
  "record_class": "Array",
  "array_length": 215,
  "first_element_classes": [
    "Array",
    "Array",
    "Array",
    "Array"
  ]
}

The diagnostic input inspected the decoded MessagePack object immediately before native Fluentd in_forward processing.

• Steps to reproduce the problem:

1. Configure Fluent Bit 5.0.7 on Windows with a winlog input and filesystem storage.

2. Configure the Forward output to send to Fluentd 1.16.11:

[OUTPUT]
    Name                            forward
    Match                           winlog
    Host                            <redacted>
    Port                            24224

    Send_options                    On
    Require_ack_response            On
    Retain_Metadata_In_Forward_Mode False

    Storage.Total_Limit_Size        2G
    Retry_Limit                     False

    Net.Connect_Timeout             10
    Net.Keepalive                   On
    Net.Keepalive_Idle_Timeout      30

1. Allow Windows Security events to accumulate in Fluent Bit’s filesystem storage.

2. Forward the stored events to Fluentd.

3. Inspect the decoded Forward messages received by Fluentd.

The problem is intermittent, and we do not yet have a deterministic minimal reproduction. It has been observed while filesystem-buffered events were being forwarded. A relationship to backlog replay, retries, acknowledgements, or connection recovery is suspected but has not been confirmed.

In one captured occurrence:

Outer tag:              winlog
Outer entry count:      153
Malformed indexes:      0 through 152
Nested batch count:     153
Nested event total:     34,182
Smallest nested batch:  38 events
Largest nested batch:   556 events
Average nested batch:   223.4 events
Outer chunk ID:         absent

Every outer entry was another complete Forward batch. For every entry, Fluentd observed:

event time:    "winlog"
record class:  Array
array members: Array, Array, Array, ...

Expected behavior

The Forward output should always serialize log entries in a standard Fluentd-compatible structure:

[tag, [[time, record], [time, record], ...], options]

Each record should be the original event map.

A complete [tag, entries] Forward message should not appear as a record inside another Forward message.

When Retain_Metadata_In_Forward_Mode False is configured, the output should use strict Forward-compatible records suitable for Fluentd.

Screenshots

N/A.

Sanitized diagnostic files and Fluent Bit logs can be provided if helpful.

Your Environment

• Version used:

Fluent Bit 5.0.7
Fluentd 1.16.11

• Configuration:

[SERVICE]
    Flush                       1
    Daemon                      Off
    Log_Level                   debug

    Storage.Metrics             On
    Storage.Path                C:\fluent-bit-data\buffer
    Storage.Sync                normal
    Storage.Checksum            On
    Storage.Backlog.Mem_Limit   128M
    Storage.Max_Chunks_Up       256

[INPUT]
    Name                        winlog
    Tag                         winlog
    Channels                    Security
    Interval_Sec                1
    DB                          C:\fluent-bit-data\db\winlog-security.sqlite
    Mem_Buf_Limit               64MB
    Storage.Type                filesystem

[OUTPUT]
    Name                            forward
    Match                           winlog
    Host                            <redacted>
    Port                            24224
    Send_options                    On
    Require_ack_response            On
    Retain_Metadata_In_Forward_Mode False
    Storage.Total_Limit_Size        2G
    Retry_Limit                     False
    Net.Connect_Timeout             10
    Net.Keepalive                   On
    Net.Keepalive_Idle_Timeout      30

• Environment name and version:

Windows host forwarding Windows Security events

• Server type and version:

Fluentd 1.16.11 using the native in_forward implementation

• Operating System and version:

Windows [edition and build to be added]

• Filters and plugins:

Input:  winlog
Output: forward
Storage: filesystem
Filters: [none, or list any configured filters]

Additional context

The objective is to forward Windows Security events from Fluent Bit to Fluentd and then to downstream storage without record gaps.

Most records are delivered successfully, but a malformed outer Forward batch can contain tens of thousands of otherwise-valid Windows events. Fluentd rejects the malformed stream with:

record must be a Hash: Array

The downstream system has observed gaps in Windows RecordNumber values.

A temporary custom Fluentd input can recognize the exact nested shape, flatten the inner batches, and submit the recovered events to native Fluentd processing. This confirms that the individual records inside the nested batches are valid. However, this is only a receiver-side recovery measure; the unexpected Forward framing originates before Fluentd processes the message.

Could the maintainers clarify:

1. Whether nested Forward batches are intentional or supported in any Fluent Bit 5.0.7 mode.
2. Whether filesystem backlog recovery can cause already-formatted Forward messages to be wrapped a second time.
3. Whether this is a known Windows-specific Forward-output or storage issue.
4. Whether there is a supported sender-side configuration that guarantees standard Fluentd-compatible serialization.
5. What additional tracing, MessagePack capture, or filesystem-chunk information would be most useful for diagnosing this.