ingestr v1.1.14 - BigQuery Schema Reconciliation

ingestr v1.1.14 was published on July 30, 2026, with a narrow correction for BigQuery column type handling. The main change defers type and kind reconciliation to schema evolution, while the concurrent create path now rejects a mismatch that it cannot reconcile.

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

The central change moves BigQuery column type and kind reconciliation into schema evolution. That boundary matters because reconciliation is no longer described as an early decision made outside the component responsible for applying schema changes.

The release notes use both type and kind deliberately, but they do not publish a compatibility table or name every affected BigQuery type. The merge description identifies an integer and float column mismatch as the issue under repair. Nothing in the notes supports a claim that v1.1.14 adds general type coercion or accepts new conversion pairs.

For data pipeline owners, this is a correctness change rather than a new feature. Existing tables can present a destination schema that differs from the incoming representation. Deferring the decision gives the schema evolution path responsibility for deciding whether that difference can be handled. It does not remove the need for a stable source schema or explicit checks around numeric columns.

No CLI flag, configuration key, or migration step is listed. The behavior is part of the BigQuery path in this release. Teams with integer and float drift should test against a representative destination table instead of assuming that every numeric mismatch now succeeds.

The second runtime change affects the concurrent create path. ingestr now rejects a type mismatch when that path cannot reconcile it. This is the safer outcome for a destination whose schema is being created while competing work observes or attempts to establish a different shape.

The word reject is operationally important. A failed load exposes the contract conflict instead of allowing an unreconciled schema difference to continue. Operators should preserve the relevant task error and compare the incoming columns with the BigQuery table schema before adding retries. A retry can help with transient creation timing, but it cannot make incompatible types compatible.

The notes do not specify the error text, retry policy, or transaction boundary for this path. They also do not claim that all table creation races are fixed. The stated scope is the unreconcilable type mismatch encountered during concurrent creation, so validation should target that case.

The remaining source change trims comments added for the type and kind deferral. That is internal cleanup with no stated runtime effect. The other changelog entry records the merge that collected the BigQuery fix.

This makes v1.1.14 a small release with two behavior changes and one maintenance edit. There are no listed connector additions, performance numbers, dependency updates, or broad schema changes. That limited surface is useful when planning validation: focus on BigQuery numeric columns, existing destination schemas, and overlapping first writes.

This is a regular release, not a prerelease. Since no breaking change or required migration is documented, the practical upgrade check is a focused load test. Exercise one compatible schema evolution case and one incompatible concurrent creation case, then confirm that the latter fails visibly in the orchestration layer.