ingestr v1.1.62 - Destination Write and SQL Fixes

ingestr v1.1.62, published on October 5, 2026, fixes a HubSpot write error propagation deadlock, an operational concern for jobs that need to fail cleanly. This release also corrects destination SQL and type handling, including StarRocks staging deduplication and string primary key widening in MySQL and Oracle. GitHub marks it as a regular release, not a prerelease.

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

The HubSpot fix prevents deadlocks during write error propagation. That distinction matters to operators. A failed write needs to produce a failure that the surrounding job can handle. A deadlock in that path can leave the job waiting when it should be reporting an error.

For a scheduled HubSpot load, this makes the failure path a useful acceptance check for v1.1.62. Exercise a controlled write failure and verify that the run terminates with an error visible to the scheduler. A successful transfer alone does not exercise the behavior this fix addresses.

The release notes do not describe the locking mechanism or promise different retry semantics. Treat this as a correction to error handling. It does not establish that failed writes are automatically retried or that partially completed work is rolled back.

The SCD2 change fixes SQL and adds coverage for ClickHouse, Trino, and Vertica strategies. For pipelines maintaining record history, the useful review target is the resulting history table. Check an unchanged record and a changed record across successive loads, then inspect which versions remain current.

The notes name those three destinations but do not identify the exact SQL defect. They support a targeted regression check for the affected strategies, without establishing a universal change to SCD2 behavior across every destination. Keep existing history expectations explicit when comparing results before and after the upgrade.

Separately, StarRocks staging deduplication now honors the incremental key. This is relevant when staging contains multiple candidate rows for the same record. The incremental key participates in deduplication, so a test containing only unique records would miss the case addressed here.

A useful StarRocks fixture has repeated record keys and distinct incremental values. Compare the selected staging result with the pipeline’s intended ordering. The notes do not specify tie handling, so equal incremental values should remain a separate case in local validation.

The CrateDB write fix preserves typed Arrow lists during writes. For a pipeline carrying list columns, row counts alone are an incomplete check. Inspect the stored list values and their types after loading a representative batch. The change concerns type preservation at the write boundary; the notes provide no throughput claim.

MySQL and Oracle handling now widens string primary keys instead of failing. This addresses a different destination contract: identifiers can outgrow the width previously accepted by the pipeline. Include a longer identifier in a validation batch and inspect both the destination column definition and the stored key.

The release notes give no widening limits or migration procedure. For an affected table, checking the resulting schema is more informative than treating a completed job as the entire acceptance criterion. These two fixes deserve separate fixtures because preserving an Arrow list type and widening a string key exercise different write behavior.