ingestr v1.1.38 - PostHog HogQL Events And Archive Pin


ingestr v1.1.38 shipped on 26 August 2026 as a stable tag, not a candidate. The change that matters for operators is the PostHog events source: it now reads through the HogQL query endpoint with keyset pagination instead of the REST events list, which silently dropped rows on wide windows.

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

Commit 4254b44 (merged in #1116) stops using the REST /events/ list for the PostHog events table. That list path hit a ClickHouse query execution time budget on multi day windows, returned a partial page, set next to null, and exited as if the read had finished. Destination tables looked complete. They were not.

The replacement is the /query/ HogQL endpoint. Pages advance with a keyset cursor on (timestamp, uuid). That avoids OFFSET, which personal API keys reject, and keeps each page under the execution time budget. Interval start and end stay in the query WHERE clause on every page, so a later page cannot drift outside the requested window.

Winners are incremental loads and backfills that span more than a day. The cost is runtime: jobs that used to stop early will now walk the rest of the window. Pipelines that keyed off REST list tokens or the old page shape will see a different wire format even when the destination column names stay the same.

HogQL will not SELECT the bare person object the REST list returned. Commit b865c15 selects person_id and person.properties and folds them back into a nested person column so existing destination schemas keep filling.

The query endpoint also has no parsed elements array. It exposes elements_chain, the packed DOM path PostHog stores for autocapture. Commit 5fa4aab rebuilds elements from elements_chain by porting PostHog’s own chain_to_elements parser, including the same regexes and rules. That reconstruction was checked byte for byte against the REST array on 100 real events, and against the Python parser on quoted and escaped strings.

Commit 8a21c04 records the split in the docs: events expose elements_chain on the wire, not a parsed array. Jobs that already consume elements should keep working if the rebuild matches. Jobs that match on the raw elements_chain string should keep that column. The two are not interchangeable without a schema check.

Pull request #1114 (commit 8b83d66) bumps github.com/moby/go-archive from v0.2.0 to v0.3.0 for GHSA-hfg8-hc9c-6c3h (CVE-2026-17106). The advisory is HIGH. A crafted tar archive can use links to create or overwrite files outside the destination directory. Affected helpers include Unpack, UnpackLayer, Untar, UntarUncompressed, and ApplyLayer.

The bump is an indirect, test only dependency through testcontainers-go. Production ingest paths in this tag do not start extracting untrusted tarballs via that module. The pin still matters for CI images, the refreshed licenses.lock.yml, and scanners that fail the build on HIGH findings. Transitive pins include moby/sys/sequential v0.7.0 and moby/sys/user v0.4.1.

Treat this as scanner hygiene plus a real extractor bug in the test stack, not as a runtime ingest fix. If a job extracts untrusted archives outside tests, that path is not what this tag changes.

No migration guide ships with the tag. The PostHog events table is the surface to recheck.

  • Confirm destination columns still include person (nested from person_id plus person.properties) and elements (rebuilt from elements_chain).
  • Rerun a known wide window against PostHog and compare row counts with the previous tag. The silent next: null stop is the bug this tag is meant to close. A higher count is the expected outcome, not a regression.
  • Keep the raw elements_chain column if downstream SQL already matches on that string.
  • The moby/go-archive bump does not require operator config.