ingestr v1.1.25: BigQuery Retries and Stripe Throughput

ingestr v1.1.25 was published on 10 August 2026. The release retries BigQuery loads, handles dataset location mismatches, changes Stripe source throughput and request handling, and fixes Oracle delete plus insert bounds on DATE keys. For jobs that incremental load into Oracle with temporal keys, the DATE bound fix is the change that decides which rows get deleted and written back.

The full release notes and downloads are on the GitHub release page. The tag is a stable release, not a beta or a release candidate.

Commit a5be672 from pull request 1076 is the destination side patch. BigQuery load jobs fail in production for two reasons that have nothing to do with schema: a transient load error, and a dataset whose location does not match the job.

A BigQuery dataset lives in a region. If ingestr submits the load against a different location, the service rejects the job. The notes say this release handles those mismatches. They do not document a new flag, a new query parameter, or a new error message. If your runs already pass, treat this as a reliability patch. If you moved a dataset between regions and loads started failing on location, this is the build to requeue first.

Retries are the other half of the same commit. Load jobs are asynchronous. A timeout, a backend 500, or a quota blip can fail a run that would succeed on a second attempt. The notes do not spell out the retry count, the backoff, or which status codes are retried. Read the commit before you loosen alerts that fire on the first load error.

Stripe is a paged HTTP API. Extract jobs that pull events, charges, or invoices spend most of their wall time on round trips and rate limits. Commit 319092d from pull request 1077 changes that source path.

The notes say throughput and request handling improved. They do not publish a new page size, a new parallelism setting, or a before and after timing. Measure extract duration on your own Stripe objects after you install v1.1.25.

Higher throughput is not free. A source that issues requests faster can hit Stripe rate limits sooner than the previous build. Watch HTTP 429 counts and retry noise after the upgrade. The changelog does not say the connector grew a new limiter, so operators still own that ceiling.

The correctness work sits on the Oracle incremental path, not on a new strategy name.

Commit 66a3637 anchors delete plus insert bounds for temporal keys in UTC. Incremental delete+insert needs a low bound and a high bound. When those bounds are DATE values, a conversion through UTC can move the calendar day. A window that should cover 10 August can cover 9 August or 11 August instead, depending on the offset. The destination then deletes the wrong slice, or leaves rows in place that should have been replaced.

Commit e853986 validates DATE bound strings and avoids that UTC wall date shift. Commit 6b76179 drops an unreachable time.Time DATE bound branch. That last change is cleanup. Commit fcef60e pins a DATE bound stringification invariant so later refactors cannot quietly change the bound format.

Pull request 1083 merges the matching tests. The notes do not list a user facing flag change. If Oracle is your destination and the incremental key is a DATE, rerun one known window and diff the table. An off by one day on the bound is easy to miss when row counts stay in the same order of magnitude.

The rest of the changelog is internal.

Release workflows now list integration matrix combinations explicitly and run a subset of tests that do not need Docker on the macOS runner. The PR workflow drops the macOS integration job. Integration tests skip container cases when Docker is missing. gofumpt and gci line wrap fixes land in tests for onelake, Stripe, and Elasticsearch.

None of that changes how rows are copied. Forks that vendor the workflow files will see a thinner macOS path on pull requests, and a skip instead of a fail when Docker is absent.

The notes do not list breaking changes or a migration step.

Still, Oracle incremental jobs with DATE temporal keys deserve a targeted rerun. A UTC wall date shift is a silent window bug. Row counts can look fine while the wrong day is being replaced.

BigQuery jobs that failed on dataset location or on flaky loads are the other set to requeue against v1.1.25.

For Stripe, compare extract duration and HTTP 429 counts. There is no schema migration on that path in this tag.

• Release notes and artifacts: GitHub release page
• Project repository: ingestr on GitHub
• Tag: v1.1.25