Hi everyone! We're running Airbyte OSS (self-hosted) with source-mysql v3.51.5, connecting to a DigitalOcean Managed MySQL instance. We're hitting the exact issue described in #75558 and discussion #74305: Failure in source: Incumbent CDC state is invalid, reason: java.lang.NullPointerException: Cannot invoke "io.debezium.connector.mysql.gtid.MySqlGtidSet$UUIDSet.getUUID()" because "other" is null Some context that might help narrow this down: - This started failing right after a DO-managed maintenance/update event on our MySQL instance (no changes on our end, no connector version change — we're self-hosted so upgrades are manual). - Our server's GTID_EXECUTED currently contains multiple historical server UUIDs (9 in production), accumulated over past failovers/maintenance events over time. This has been the case for a long time without issues. - A full "Clear data + resync" temporarily fixes it, but the very next incremental sync fails again with the same error — consistently, without any further infrastructure change in between. We understand there's a confirmed upstream fix (Debezium DBZ-9682, bumping to 3.4.2.Final) but it hasn't landed in a released source-mysql version yet. Question: does anyone know exactly what the "Incumbent CDC state" validation compares internally? Specifically — is it comparing against GTID_EXECUTED, GTID_PURGED, or the difference between the two? Trying to understand precisely what changes on the MySQL side (e.g. a UUID's range becoming fully purged from retained binlogs) triggers the mismatch, so we can anticipate/avoid it rather than just resetting reactively each time. Thanks in advance for any insight!