I've also added a log message so that if we find some data missing we can know what is it all about. If you don't find it necessary we can remove it.

Handled nullability of DTSTART of recurring instances by setting the local value to null, which would re-create the local instance.

What would that mean in our case? Do I understand it correctly that

• the main VTODO (without RECURRENCE-ID) is normally created/updated,
• and what happens with the VTODO with RECURRENCE-ID;TZID=America/New_York:20250228T130000? It seems to be added instead of updated in the code – is it deleted before so that it doesn't add a new instance for every sync?

How about adding a test to verify and document correct behaviour?

I've been looking at how to test this properly, and if I am not wrong, that would mean creating a new test class just like SyncManagerTest, but for JtxSyncManager, and checking whether it can handle those cases correctly right? @rfc2822 can correct me otherwise. I think it's actually a lot of code for just a "side-hustle".

Of course we can add it, but is it really worth it?

Of course we can add it, but is it really worth it?

I'd say yes definetly - If the test is relevant we should add it and in this case I find it highly relevant to properly understand (#1336 (comment)), clamp and document the newly added behaviour.

At least we have a specific iCalendar we could test with… it's surely at least worth the try. If it's absolutely too cumbersome we can still cancel it then

What would that mean #1265 (comment)? Do I understand it correctly that

• the main VTODO (without RECURRENCE-ID) is normally created/updated,
• and what happens with the VTODO with RECURRENCE-ID;TZID=America/New_York:20250228T130000? It seems to be added instead of updated in the code – is it deleted before so that it doesn't add a new instance for every sync?

Did you already had a look at that?