fix(source-intercom): use state for parent stream requests and use global state

[brianjlai]

What

I was investigating a couple of suspicious failures as a result of when #53187 was originally released. The failing syncs couldn't be replicated locally, but my changes put our connector more in line with how it previously worked

regression tests to follow

How

I noticed that on the original release, we forgot to indicate on the conversation_parts stream that state should be passed when making the parent stream request to incrementally get parent records. We did this on the deprecated custom component and might be the reason for the hanging syncs.

Also, upon inspecting the manifest more, we should also be using global_substream_cursor because the previous implementation did not require tracking per-parent state management.

I also noticed that we were having a few issues w/ hanging syncs on substreams. This is because the arbitrary/custom state that intercom used to write since the custom cursor used to write doesn't fit quite how our actual concurrent cursors work. Concurrent per-partition state requires parent state be under parent_state.conversations. I added a state migration to copy the parent state to parent_state.conversations which fixed the issue so we use incoming state to reduce the amount of parent records fetched.

Review guide

1. manifest.yaml

User Impact

Should be none, but the underlying state format might look a little different

Can this PR be safely reverted and rolled back?

• YES 💚
• NO ❌

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 9, 2025 11:11pm

[brianjlai]

regression test results:
https://github.com/airbytehq/airbyte/actions/runs/14367791213/job/40284726039

analyzing results:

• There is a catalog mismatch, I'm not too concerned about this, between what is in prod 0.12.2 the previously paused rollout, and this one, there were some CDK version bumps and my changes are unrelated
• There is a 2 record mismatch, I attribute this to a time drift in between control vs candidate runs. The stream is relatively high volume. I've tested the conversation_parts stream locally since my changes affect it and it shouold be working as expected
• All other stream counts line up.

[brianjlai]

/approve-regression-tests see above comment about results

Check job output.

✅ Approving regression tests

[maxi297]

[maxi297]

Confirming that this is done cause there are usually so many conversations that we assume we will hit the per partition limit and therefore we're fine with having a global state.

Benefits:

• Easier to understand state

Drawback:

• Duplication that would not have occurred for people with very small syncs where we don't this the per partition limit