ingestr v1.0.66 - OneLake Fabric Path Filtering

ingestr v1.0.66 was published on July 6, 2026 at 13:28:22 UTC. This release is a narrow OneLake fix: the project now skips Fabric managed area directories while working with OneLake table paths. For ELT operators, the important point is not breadth; it is avoiding Fabric owned directory state during table path discovery.

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

The only implementation bullet in v1.0.66 is onelake: skip fabric-managed area directories. That means this post is not a broad connector roundup. The change sits in the boundary between ingestr and Microsoft Fabric OneLake, where a pipeline can see both user table data and platform managed directory structure.

The practical value is filtering. A sync that walks or resolves OneLake table paths should not treat Fabric managed areas as user data. If that boundary is too loose, operators can see noisy path selection, unexpected attempts to process platform directories, or a higher chance of confusing a managed area with a table location. The release notes do not claim a schema change, a new connector, or a CLI flag. They point to a tighter exclusion rule in the OneLake path code.

Data lake paths are operational contracts. When a tool reads too much of the namespace, failures show up far from the code that caused them: odd table names, empty loads, duplicate path checks, or permission errors against directories that were never meant to be read by the job. v1.0.66 is small, but it touches that class of failure.

This matters most for Fabric shops where OneLake is shared by human users, managed services, and scheduled ELT jobs. The release note does not say ingestr changes how rows are extracted or written. It says ingestr is more selective about Fabric managed directory areas. That is a path hygiene fix, and it is the kind of change that reduces false work during table discovery.

There is also a deployment angle. Because the notes list only one code change and one merge commit, this release should be evaluated as a targeted patch rather than a feature release. Test it against the OneLake paths used by your jobs. Check that expected tables still resolve and that Fabric owned directories are ignored. Avoid reading a wide intent into the changelog; there is no mention of new auth behavior, schema migration, or destination format changes.

The changelog contains commit e56d6a9e4d7065fb024f8e6105ffd2d27f3ffc41 for the OneLake directory skip and merge commit b432815327e0ec3c3d8c0f812c0b98c7c0de8f59 for pull request #924. That is the full public scope in the release notes. There are no listed breaking changes.

The absence of breaking change notes does not remove the need for a small regression pass. Any path filter can be wrong in two directions. It can miss a Fabric managed area and keep the old noise. It can also filter too broadly and hide a valid table path if naming overlaps with a managed directory pattern. The release notes do not provide the exact directory names or matching rules, so validation should use your real OneLake layout rather than a synthetic empty workspace.

For teams that do not use OneLake, there is little visible surface area in this tag. The notes do not mention Postgres, Snowflake, Arrow, MySQL, or generic schema evolution behavior. Keep the rollout simple: upgrade where OneLake table path handling matters, and leave unrelated connector expectations out of the review.