ingestr v1.0.65 - Arrow Offset and OneLake Fixes

   |   3 minute read   |   Using 598 words

ingestr v1.0.65 was published on July 6, 2026, with a practical fix in the data buffer path. The main change is that Arrow array offsets are now honored when casting, which matters when sliced arrays move through an ingest job. This release is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

Arrow offsets matter when casting

The most important runtime fix in v1.0.65 is in databuffer. The release notes say ingestr now honors Arrow array offsets when casting.

That sounds small, but it is the kind of small that matters in data pipelines. An Arrow array can point at a slice of a larger buffer. The offset tells readers where the active values begin. If casting code ignores that offset, the job can read the wrong values even though the array shape still looks valid.

For users, this is a correctness fix. It is not a new connector or a new CLI option. It is lower in the stack, closer to the memory layout that source and destination code depend on. Those fixes are easy to miss in a changelog, then painful to debug when a sync produces shifted or odd looking records.

OneLake paths get stricter

There are two OneLake entries in this release. ingestr keeps area directory materialization, and it skips managed lakehouse path prefixes.

Read together, those changes point at cleaner behavior around OneLake layout. Directory materialization still happens where ingestr needs its own area. At the same time, managed lakehouse path prefixes are skipped, so ingestr avoids treating platform managed parts of the path as normal output directories.

That matters for operators who run repeatable loads into OneLake. Path handling bugs tend to show up as strange directory trees, duplicate path segments, or writes in a location that nobody wanted to own. This release narrows that risk by being more careful about which path segments ingestr should create.

CDC cursor metadata gets more context

The CDC change tags resume cursor lookup with ingestr_step. Resume cursors decide where a CDC run continues reading, so metadata around that lookup is useful when a pipeline needs inspection.

The release notes also include a BigQuery CDC metadata branch name in the merged pull request list. The explicit change called out in the commit list is the ingestr_step annotation, so that is the part users should treat as concrete from this release.

For operators, the value is traceability. When cursor state is attached to the step that touched it, it is easier to connect a run, a source, and a resume point. That does not remove the need to monitor CDC jobs, but it gives the metadata a sharper label.

Source parsing and source work are cleaner

This release also adds a rule to parse table string query params through shared pkg/tablespec code. That is a consistency fix more than a feature. Shared parsing reduces the chance that one source reads table options differently from another source.

The notes also mention an add-source agent skill for implementing new ingestr sources. That is contributor tooling, not a runtime feature for most users. Still, it matters for a connector heavy project. If source setup follows a shared path, new sources are less likely to copy old mistakes.

There is also review cleanup around register.go registration and per source readParallel. That reads as internal maintenance. The useful part is that source registration and parallel read settings are being tightened near the code paths that every connector eventually touches.

Where to get it



denis256 at denis256.dev