ingestr v1.1.25 - BigQuery and Oracle Correctness

ingestr v1.1.25 was published on August 10, 2026. The main operator facing change is more careful BigQuery load retry handling, including dataset location mismatches that can otherwise turn a recoverable destination operation into a failed pipeline run. Oracle temporal bounds and Stripe request processing also receive targeted fixes.

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

The BigQuery destination now handles load retries and dataset location mismatches. Those concerns belong together at the destination boundary: a retry is only useful when it preserves the correct dataset context. The release notes do not name new configuration keys or a migration step, so this reads as a runtime correction rather than a new operator interface.

For production pipelines, the practical check is straightforward. Review jobs that have previously failed during BigQuery load retries, especially where datasets live outside the default location. The notes do not promise automatic recovery for every BigQuery error, so existing alerting and retry limits should remain in place.

The Stripe source also improves throughput and request handling. No benchmark, concurrency value, or new tuning flag is included in the notes. Treat this as a source path improvement, then compare request rate, extraction duration, and Stripe API errors against the baseline from the prior version. That gives operators evidence without assigning performance numbers that the release does not provide.

Oracle delete and insert bounds for temporal keys are now anchored to UTC. A related fix validates DATE bound strings and avoids a UTC wall date shift. This is the most important correctness change for Oracle users because a shifted boundary can select the wrong rows even when the pipeline completes successfully.

The release also pins the DATE bound stringification invariant in strategy tests. That test is relevant to future changes in time conversion because it records the expected representation instead of leaving it implicit. A small refactor removes an unreachable time.Time branch from Oracle DATE bound handling. That part is internal cleanup, not a new capability.

Teams using temporal keys should compare boundary rows before and after the upgrade. Pay particular attention to values near midnight UTC and to delete and insert runs that use Oracle DATE columns. The notes do not report a schema change or require a data rewrite, but validating a representative boundary window is still appropriate where replacement logic can delete rows before inserting them again.

The integration test strategy now skips container tests when Docker is unavailable. A Docker free subset runs on the macOS release leg, and the release matrix lists its combinations explicitly. At the same time, the separate macOS integration job was removed from the pull request workflow.

These are mostly release engineering changes. They do not alter connector behavior by themselves. They do make the intended coverage easier to see: macOS exercises tests that do not require containers, while container dependent paths remain tied to environments with Docker. Formatting changes across OneLake, Stripe, and Elasticsearch tests are also internal and should have no runtime effect.

There are no breaking changes or migration steps listed for v1.1.25. The focused validation targets are BigQuery retry cases, Oracle temporal boundaries, and observed Stripe request behavior. The exact change list remains available on the v1.1.25 release page.