How does airbyte handle replaying data when a sync fails in the posthog connector (open source)? If a sync fails, does the next sync try to pick up where it left off? Which was my understanding but it seems some data is missing on certain months

The knowledge sources don’t mention the PostHog connector specifically, so I can only describe the general Airbyte behavior and where gaps might come from. 1. Airbyte is “at-least-once” and resumable Airbyte is designed so that when a sync fails, the next sync tries to resume instead of starting from scratch. It will keep retrying as long as the source can produce records and the destination can commit them. This means some records may be delivered more than once, but they should not be skipped by design. [Resumability] 2. How “picking up where it left off” works (state & checkpointing) ◦ Sources emit state messages that represent a checkpoint (e.g., “I’ve replicated up to here”). ◦ The destination only “accepts” a state once it has successfully committed all records up to that state. ◦ On the next run, Airbyte passes back only the last state that was successfully committed by the destination, and the source uses that to decide where to resume. [State & checkpointing; State & whole sync] If a failure happens after the source emitted some records but before the destination committed them and emitted the corresponding state, those records must be re-sent on the next sync. [State & whole sync] 3. What happens on a failed sync ◦ Airbyte will retry the sync (by default up to 3 times in the OSS platform). [What happens if a sync fails?] ◦ Once the issue is resolved and a sync finally succeeds, Airbyte resumes from the last committed state, not from the very beginning. [State & checkpointing] 4. Why you might see missing data for some months The docs do not provide connector‑specific details for PostHog, so they don’t explain your exact symptom. However, based on the protocol behavior, missing data would usually indicate one of these situations (none of which I can confirm from the docs, only infer from how state works): ◦ The connector’s state logic (how it chooses and updates its cursor) might be incorrect or too coarse, causing it to “jump over” some records when resuming. ◦ The connector might not be emitting state frequently enough, so a failure causes a larger gap between the last committed state and the actual last record read. ◦ There could be source-side filtering or windowing (e.g., date filters) that interacts badly with the state, leading to some months not being re-queried. Because the knowledge sources don’t include the PostHog connector implementation or known bugs, I can’t say exactly which of these is happening in your case. ------------------------- What you can do next Given the limitations of the docs: • Check the connection’s sync mode (e.g., Incremental vs Full Refresh) and cursor/primary key configuration in the UI. • Inspect the logs around the failing sync and the first successful sync after that to see what state values are being emitted and used. [What happens if a sync fails?; State & checkpointing] • If you can reproduce missing months, it’s likely a connector bug; the forum post suggests opening a GitHub issue with logs for investigation. [What happens if a sync fails?] If you share specific log snippets (state values, cursor fields, and the time window where data is missing), I can help you interpret them against the state/checkpointing behavior described in the docs. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.