We are experiencing an intermittent issue where several custom connectors appear to lose their incremental sync state. When this happens, the connectors begin retrieving significantly more data than expected. Expected behavior: The affected streams run hourly and typically ingest only a few hundred new records per sync. Observed behavior: At seemingly random points, the incremental state becomes invalid or is ignored, and the connector starts fetching thousands of records per execution, effectively reprocessing historical data. The issue resolves by updating the connection state. It does not resolve after refreshing data (without deletion). The issue appears to be related to connection state management and/or date cursor handling. Based on our observations: • The problem is intermittent and not reproducible on every sync. • Once it occurs, the saved state appears to point to an incorrect cursor value or is no longer being honored. • Resetting the connection state to a more recent date temporarily mitigates the issue, after which incremental syncs resume behaving normally for a while. • We suspect there may be an issue related to datetime parsing, serialization, or state persistence causing the incremental cursor to become invalid. Impact • Significant increase in API calls. • Unexpected ingestion of historical records. • Increased compute and database load. • Potential duplication and downstream processing overhead.

here are the yaml files for our connectors, we're having issues with the following: • respira_air_gradient.yaml: ◦ Affected stream: Respira_measures_past ◦ Destination: Postgres ◦ Sync frequency: 1 hour • mades_open_data.yaml: ◦ Affected streams: MADES-Open-pm10_data, MADES-Open-pm25_data ◦ Destination: Postgres ◦ Sync frequency: 1 hour