Hello 👋 I have an Intercom connector with a lookback_window = 1 day, with streams

conversations

(incremental | append+deduped) and

conversations_parts

(incremental | append+deduped) 👉 I have missing

conversations_parts

:

statistics.count_conversation_parts

on conversation does not match the number of parts for this conversation in

conversations_parts

Am I missing something ? Thanks 🙏

Interesting. What does

statistics.count_conversation_parts

actually count as a part? Could you check that it counts the same things that

conversation_parts

count?

From the API doc :

count_conversation_parts

(integer) Total number of conversation parts. 👉 a part is a message, a note, an assignment... It should be the same : when we call the Intercom API for a conversation, we get more parts than what's available in the Airbyte table. We’ve manually verified this across several conversations and parts. We've ignored conversations that are missing only one part, but we found some that are missing more than 10 parts.

A few questions to help narrow this down: 1. Sync history around the affected dates - Were there any failed or interrupted syncs between April 19–26? Also, is this a new issue or has it been recurring? 2. Rate limiting - Do your sync logs show any rate limit errors from Intercom? Since

conversation_parts

is a sub-stream of

conversations

, if the parent stream hits rate limits or errors during pagination, some conversations may not be fetched at all, meaning none of their parts get synced for that run. 3. 3. Specific missing parts - For a conversation with missing parts, could you compare the

updated_at

timestamps of the missing parts against the sync schedule? Specifically: Were the missing parts created during a sync run (i.e., after the sync started but before it finished)? Or were they created between two syncs and still missed? This will help us determine whether the issue is with the client-side incremental filter or with conversations not being fetched by the parent stream.

1. The last sync failure occurred in October 2025. All subsequent syncs have been successful. It seems this issue has existed since the beginning, but we've only just noticed it. 2. I found no logs indicating that the rate limit was reached; all syncs were completed in a single attempt 3. The missing components were neither created nor updated during the sync process, but between two syncs, and are still missing (I've checked two conversations created on different days: one with 10 missing parts and one with 77 missing parts).

This is weird. For one of the conversations with missing parts, could you call

GET /conversations/{id}

directly and check the

updated_at

field on the missing parts? Specifically: • Do the missing parts have`updated_at = 0`or some other unexpected value? • Or do they have normal, recent`updated_at`timestamps?

Here is an exemple of a conversation with missing parts :

I compared your API response (44 parts) against the Airbyte table (38 parts) and identified the 6 missing parts. In every case, the missing parts were created seconds or minutes before other parts on the same conversation that WERE synced. The connector's client-side filter (

should_be_synced

) dropped them because their

updated_at

fell just behind the global cursor. The issue: this filter uses the previous sync's duration (a few minutes) as its lookback, not the configured

lookback_window

(1 day). So parts even slightly behind the cursor get silently dropped. You could run a full refresh on

conversation_parts

to recover missing parts, but the issue will recur on incremental syncs. I'm filing a GitHub issue on the Airbyte Python CDK repo for this.

Thank you 🙏

There's a backlog of issues and our team is working through it. That said, I don't have an ETA for completion. Thanks for you patience!