Problem
When a persisted cursor state value cannot be parsed with the stream's configured cursor_datetime_formats, ConcurrentPerPartitionCursor._set_global_state() lets the raw ValueError escape during stream construction. The sync dies before any record is read, and the user-facing failure is:
No format in ['%s', '%s'] matching 1698686995.0
Observed in production on a manifest-only source (source-slack, threads stream) where the stored global cursor value carried a fractional epoch ("1698686995.0") while the stream declares cursor_datetime_formats: ["%s"].
Why the current message is poor
- Leaks implementation details (
%s format tokens, an internal Python list) with no user-meaningful vocabulary.
- Does not say which stream, which cursor field, or that the value came from saved sync state.
- Offers no remediation (e.g. "refresh/clear the stream state").
- Classified as
system_error / failure_origin: source, so it looks like a connector crash rather than an unparseable-state condition.
- Duplicate entries in the format list (
['%s', '%s']) because CustomFormatConcurrentStreamStateConverter.__init__ appends datetime_format to input_datetime_formats, which makes the message look nonsensical.
Suggested improvements
- Wrap the failure in an
AirbyteTracedException with a config_error-style (non-system_error) failure type, naming the stream, the cursor field, the offending value, and the accepted formats, plus a remediation hint pointing at refreshing the stream's state.
- Consider mirroring the tolerance already added for record cursor values in #758 (
observe() logs a warning and skips instead of raising) so a single unparseable state value degrades to a warning rather than failing the sync.
- De-duplicate the formats reported in the message.
References
Devin session
Problem
When a persisted cursor state value cannot be parsed with the stream's configured
cursor_datetime_formats,ConcurrentPerPartitionCursor._set_global_state()lets the rawValueErrorescape during stream construction. The sync dies before any record is read, and the user-facing failure is:Observed in production on a manifest-only source (
source-slack,threadsstream) where the stored global cursor value carried a fractional epoch ("1698686995.0") while the stream declarescursor_datetime_formats: ["%s"].Why the current message is poor
%sformat tokens, an internal Python list) with no user-meaningful vocabulary.system_error/failure_origin: source, so it looks like a connector crash rather than an unparseable-state condition.['%s', '%s']) becauseCustomFormatConcurrentStreamStateConverter.__init__appendsdatetime_formattoinput_datetime_formats, which makes the message look nonsensical.Suggested improvements
AirbyteTracedExceptionwith aconfig_error-style (non-system_error) failure type, naming the stream, the cursor field, the offending value, and the accepted formats, plus a remediation hint pointing at refreshing the stream's state.observe()logs a warning and skips instead of raising) so a single unparseable state value degrades to a warning rather than failing the sync.References
airbyte_cdk/sources/streams/concurrent/state_converters/datetime_stream_state_converter.py(CustomFormatConcurrentStreamStateConverter.parse_timestamp)ConcurrentPerPartitionCursor._set_initial_state→_set_global_state→parse_valueDevin session