InfluxDB 3 Enterprise WAL conversion error during historical writes, without triggers

We use InfluxDB 3 Enterprise with an at-home licence, packaged as Home Assistant app 1.1.3 on Raspberry Pi 5. The app maintainer’s changelog identifies Enterprise 3.11.4; the running binary version has not been independently confirmed. The maintainer directed us to InfluxData: InfluxDB3 Enterprise processing-engine WAL conversion error with no configured triggers · Issue #63 · erik73/app-influxdb3 · GitHub

During bounded historical migration from InfluxDB 1 through /api/v3/write_lp, the server repeatedly logs:

influxdb3_processing_engine::ent::wal: failed to convert WalFlushTableData to RecordBatch: cannot convert WalFlushTableData to RecordBatch

Writes use nanosecond precision, accept_partial=false and no_sync=false. The client checkpoints each chunk and compares timestamps, tag sets and field values against the source, with field schema checks. A client log guard stops further work on database errors; its wrapper unfortunately suppresses the underlying exception as a generic trial error. We are not asserting that the server itself crashes.

Both relevant destination databases reported zero processing-engine triggers. Authenticated health checks passed. Read-only comparisons of two interrupted intervals matched all 9,630 and 15,680 points respectively, with none missing, stable source rereads and unchanged checkpoints. These checks do not establish global integrity or explain the error.

The error recurred in limited trials on 14 and 15 September 2026. The latest trial followed user-reported Home Assistant updates/restart; we have not established whether the InfluxDB container itself restarted. It verified one batch and then stopped, leaving 3,875 checkpointed chunks and 5,041,471 verified points. The newest interrupted interval still needs comparison. Latest recorded destination memory was about 718 MB, below the client’s 2 GiB safety threshold, with CPU low. Retained logs contained 27 matching conversion entries, latest 2026-09-15 00:54:36 UTC.

The migration remains paused. No processing components or safety guards have been disabled. Original data remains in InfluxDB 1. No credentials, raw logs, private URLs or source data are included here. Forum searches for WalFlushTableData and RecordBatch found no exact matches.

Is this a known Enterprise defect? What credential-safe diagnostics would identify its cause, and is there a supported fix or workaround preserving existing history and write durability? Does this error affect only processing-engine conversion, or can it affect persisted/queryable data even when an immediate comparison passes?