TypeError: Unsupported operand types: string + int in Drupal\smart_date\Plugin\migrate\process\ParseDates->transform()

Casting the $k is definitely a good place to start. It does seem like the code is expecting numeric keys but your data has some strings, so it's possible other issues will arise, but it's worth a try.

It turns out that it was a mistake on my part. The problem was in the way I was accessing the D7 date field in the migration yaml.

I was doing source: field_date instead of source: field_date/0/value. I found this out after adding the type casting changes and re-trying to update migration.

The error msg was SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'field_smart_date_end_value' cannot be null, and so it became clear that field data was not correct.

Sorry for the inconvenience, I believe the status can be set to "closed works as intended"?

Great, thanks for the follow-up. Is this something that should be documented?

I've run into this same issue with a D7 date_repeat field, including getting the follow-up error 'field_smart_date_end_value' cannot be null. While trying to handle that, I came to a different conclusion.

The migration plugin is written to handle all the field values for the migrating row at once, but the migration system was passing values one by one. That meant that, rather than being a field deltas, $k was value, value2, or rrule. After casting $k as (int), the key the plugin was trying to access for the end value wasn't present - it was that very key that had been casted.

The solution in MR!117 was adding the migration plugin annotation handle_multiples, which tells the migration system to pass in all the row's field values at once. That's the input the plugin expects, and it resolved all the errors I encountered. All the instances of my repeating dates were created correctly.

Any UNTIL date of the rrule isn't being converted from D7 date format, but that's a separate issue.

Interesting! It does seem like this does indeed align with how the class was written, and it seems like a "low risk" solution, but I would love to get some additional community feedback on this one before we commit the change.