ingestr v1.0.70 - OneLake Paths And Partitioned Extraction

ingestr v1.0.70 was published on July 7, 2026, with changes around partitioned extraction, OneLake path handling, and Iceberg credential coverage. The main operator visible change is support for partitioned extraction, which affects how extraction jobs can be scoped and replayed in data movement workflows.

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

The release includes support for extract partitioned extraction. The note is compact, but the operational meaning is clear enough: extraction can now be shaped around partitions instead of treating the source as one undivided pull.

For ETL jobs, partition boundaries are usually where restart behavior, backfill scope, and cost control become concrete. A table or endpoint that can be read by partition gives operators a smaller unit to retry when a job fails. It also gives schedulers and wrappers a cleaner way to map source work to target writes.

The release notes do not describe the external CLI surface or configuration syntax for this change. That means the cautious reading is that v1.0.70 adds the project side support, not a broad documented workflow change in these notes. Teams using ingestr in scripted jobs should test the exact source and target pair before moving partitioned extraction into scheduled runs.

This is the change that matters most for data engineers because it changes the shape of extraction work. Everything else in the release is mostly target validation, path parsing, or test hardening.

The OneLake related commits make target parsing less ambiguous. v1.0.70 accepts period separated Delta table targets, detects the Files area on the first path segment, and rejects empty table targets or targets that stop at the area root.

That is useful plumbing for Microsoft Fabric and OneLake layouts where names can carry structure. Period separated Delta targets are common enough that rejecting them forces awkward naming workarounds. Accepting them makes ingestr easier to fit into existing lakehouse naming conventions.

The rejection path is just as important. Empty targets and area root targets are usually configuration mistakes, not valid destinations. Failing early is better than writing to a broad path, creating an unexpected object layout, or letting a later write fail after extraction has already consumed source capacity.

The Files area detection change also points at a practical source of errors: a path can mean different things depending on whether the first segment is part of the storage area or part of the logical table path. Getting that split wrong can put data in the wrong branch of a lakehouse layout.

The release includes a test guard that CommitTable uses catalog S3 credentials. That is not a feature headline, but it is the kind of guard that matters in production Iceberg paths.

Iceberg commit behavior touches catalog state and object storage. If a commit path uses the wrong S3 credentials, the failure mode can be noisy or worse, environment dependent. It might pass in a broad local profile and fail under a narrower service identity in CI or production.

The notes also mention an idempotent createIcebergBucket helper and gofumpt formatting for Iceberg tests. Those are internal maintenance items. They do not change a public operator workflow by themselves, but they reduce test fragility around object storage setup.

For platform teams, the takeaway is narrow: v1.0.70 adds more confidence around the credential boundary used by Iceberg table commits. It does not claim new Iceberg user features in the release notes.

The OneLake validation changes can expose bad configuration that older runs may have accepted for longer. Empty table targets and area root table targets are now rejected. If an automated job builds OneLake destinations from variables, check the rendered target string before rollout.

Period separated Delta targets should now be accepted, which may remove local patches or naming workarounds. Treat that as a cleanup opportunity after a staging run, not as a reason to change working table names during the same deploy.

For partitioned extraction, verify behavior on a bounded dataset first. The release notes do not list a breaking migration step, but partition scope changes can affect retry semantics, target overwrite logic, and the size of each extraction unit.

The GitHub release page is the source of record for the exact changelog.