Skip to content

fluentbit: upgrade to v4.2.8 and pin dependencies - #6

Merged
solsson merged 1 commit into
mainfrom
fluentbit-4.2.8-format-requirements
Aug 10, 2026
Merged

fluentbit: upgrade to v4.2.8 and pin dependencies#6
solsson merged 1 commit into
mainfrom
fluentbit-4.2.8-format-requirements

Conversation

@solsson

@solsson solsson commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

fluentbit: v4.2.8, pinned Arrow, and the format requirements written down

  • FLB_VERSION 4.2.2 → 4.2.8.
  • Arrow glib pinned to 25.0.1-1. The apt source package is published only as
    "latest", so this was the one unpinned input in an otherwise digest-pinned
    build.
  • New images/fluentbit/REQUIREMENTS.md: the invariants compact_columns.c
    exists to hold, which were nowhere stated as requirements. An object written
    wrong is unreadable for its whole 365-day retention.
  • test.sh now asserts the arrow schema (R1 time is timestamp[ns], R3
    stream/logtag are int8-dictionary) using the pyarrow validator it already
    ran but never checked — output was captured with || true and echoed. With
    dictionary encoding in place the DuckDB assertions can only ever SKIP, so the
    arrow format was effectively unguarded.
  • Fixes two comments that stated the opposite of the truth: compact_columns.c
    claimed nanoarrow reads dictionary columns back as VARCHAR (it fails at
    schema decode), and compact_columns.h claimed no body compression while the
    code sets ZSTD.
  • README described a build//example/ layout that no longer exists and
    parquet-only output that production dropped.

Not in scope

Dictionary encoding stays (decided 2026-08-10). Removing it costs +1.77%
aggregate over a 102-object sample of a production day and is a two-sided
trade; the time-column normalization is what carries compact_columns (+6.6%).
The consequence — DuckDB cannot read our .arrow objects — is documented in
REQUIREMENTS.md along with why the upstream fix is further off than
duckdb-nanoarrow#25 suggests. arrow-go and pyarrow read them natively, so
nothing operational is blocked.

Base image digests are not refreshed here, deliberately: a mechanical change
better kept out of the run that validates the version bump.

Verification

  • All three patches apply to a real v4.2.8 checkout;
    apply-compact-compression.sh under GNU sed still lands
    ARROW_COMPACT/PARQUET_COMPACT at 5/6 with no collision, all 8 expected
    files modified.
  • Pinned Arrow install resolves: pkg-config --modversion arrow-glib → 25.0.1.
    Both amd64 and arm64 carry the version.
  • bash -n test.sh clean.
  • The k3d e2e was not run locally (needs a full fluent-bit compile) — that
    is what this PR's CI is for.

Risk

Assertion 7a2 hard-fails when the arrow-inspect pod produces nothing, where
that was previously tolerated. Intended, but it will redden CI if that pod is
flaky for infra reasons rather than passing quietly.

🤖 Generated with Claude Code

…down

Bumps FLB_VERSION 4.2.2 -> 4.2.8. The 186 intervening commits touch none of
the files our three patches target; verified by applying all three against a
v4.2.8 checkout, including apply-compact-compression.sh under GNU sed, which
still lands ARROW_COMPACT/PARQUET_COMPACT at 5/6 without colliding.

Pins the Arrow glib packages to 25.0.1-1. The apt source package is published
only as "latest", so the same Dockerfile was building against whatever Apache
Arrow shipped that day - the one unpinned input in an otherwise
digest-pinned build. Both amd64 and arm64 carry the version; verified the
pinned install resolves (pkg-config --modversion arrow-glib = 25.0.1).

Adds REQUIREMENTS.md, because the invariants compact_columns.c exists to hold
were nowhere stated as requirements - only as status notes in LOGS_STATUS.md
and as a known limitation in this test harness. An object written wrong is
unreadable for its whole 365-day retention, so these need to be findable from
the code that writes them.

Two comments claimed things that are false, which is worse than silence
because they let the next reader confirm a wrong conclusion on paper:

- compact_columns.c said DuckDB/nanoarrow reads dictionary columns back as
  plain VARCHAR. It does not: nanoarrow fails at schema decode with "Schema
  message field with DictionaryEncoding not supported", reproduced against a
  real production object with duckdb 1.5.5 and the current extension build.
- compact_columns.h said the IPC writer uses no body compression, while the
  implementation two files over sets ZSTD.

Dictionary encoding of stream/logtag stays, decided 2026-08-10. Removing it
costs +1.77% aggregate over a 102-object stratified sample of a production
day (22,235 rows, 12 namespaces) and would be a two-sided trade anyway - the
median object is ~4.7% smaller without it. It is the time-column
normalization that carries compact_columns: reverting only that costs +6.6%.

The consequence of keeping it is that DuckDB cannot read our .arrow objects,
and that is further off than the tracking issue suggests. Upstream nanoarrow
gained dictionary decode in 0.9.0 (2026-07-31), but the DuckDB extension pins
nanoarrow at a 2025-01-09 commit, 148 behind, still only accepts RecordBatch
messages in its IPC loop, and has no PR on duckdb-nanoarrow#25. arrow-go and
pyarrow both read these files natively, so nothing operational is blocked.

That leaves the arrow schema guarded by DuckDB assertions that can only ever
SKIP. test.sh already ran a pyarrow validator that can read the files but
never asserted on its output - it was captured with || true and echoed. It
now asserts R1 (time is timestamp[ns]) and R3 (stream/logtag are
int8-dictionary), so a regression in either fails the build instead of
printing past it. R2 (ZSTD, never LZ4) stays documented but unasserted: the
codec is a flatbuffer enum that pyarrow reads transparently and does not
expose, and the reader that would reject LZ4 cannot get past R3 to try.

README described a build/ and example/ layout that has not existed since the
images/ and k3d-example/ reorganisation, and a parquet-only output that
production dropped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@solsson
solsson merged commit ac90a1b into main Aug 10, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant