ingestr v1.1.31 Adds Run Tracing To Pipeline Rows

ingestr v1.1.31, published August 14, 2026, adds an _ingestr_run_id column so pipeline output can be traced to the run that wrote it. The same run identity now appears in managed staging table names, tightening the connection between stored rows and temporary load state.

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

The central change is _ingestr_run_id, a metadata column added by the pipeline for run tracing. It gives loaded rows an explicit run identifier that operators can use during reconciliation, incident analysis, and targeted data quality checks. The value is more useful than a timestamp alone because it names the execution rather than merely describing when a row appeared.

This field should be treated as operational metadata. Consumers that enumerate every column, hash complete rows, or enforce strict destination schemas should account for the additional field before adopting the release. The release notes do not describe a compatibility switch or an opt out path, so existing schema assumptions deserve a direct check in a representative pipeline.

The release also limits run ID comments to at most two lines. That is a smaller change, but it places a clear bound on how much comment text is attached to the identifier and keeps that diagnostic surface compact.

Managed staging table names now embed the run ID. A related fix aligns generated run IDs with those table names, while a small refactor moves run ID generation inline. Together, these changes make the identifier consistent across the staging object and the metadata written into pipeline output.

That consistency matters when a load stops between staging and final write. An operator can compare the _ingestr_run_id value with the identifier visible in a managed staging table name, instead of correlating objects only by timing and surrounding logs. It also gives cleanup investigations a concrete key when several runs use the same source and destination close together.

The changelog does not claim any change to staging table retention or cleanup policy. The embedded identifier improves correlation, but it is not a complete audit log and should not be treated as one.

Adding reserved run metadata creates a schema risk when an incoming field normalizes to the same destination name. Version v1.1.31 detects normalized collisions involving run and load metadata columns during pre-stage. The normalized part is important: source names that differ before normalization can still compete for one metadata name later in the pipeline.

This check gives operators a defined failure point before staging proceeds with an ambiguous mapping. It also protects the meaning of _ingestr_run_id; a source field should not silently occupy the column intended for pipeline tracing.

The related tests cover the run ID across multiple table, streaming, and CDC paths. That breadth is useful because each path can exercise staging and metadata handling differently. It is test coverage, not a claim that connector behavior or CDC semantics changed in this release. No new source or destination is listed in the notes.