What I find a bit odd is that we already try to catch exceptions in Command/Sync.php on all getEntry calls, so that should already take care of it, no?

Indeed. I just noticed that the actual error wasn't an exception. It was PHP Fatal error: Uncaught Error: __clone method called on non-object in /usr/share/roundcubemail/plugins/libcalendaring/lib/libcalendaring_vcalendar.php:633, so to catch it we'd have to catch Throwable, I suppose, I'm not sure.

Still, it makes sense to not skip the entire message, but sync it as it was a normal message, ignoring the fact it has an invitation.

In D4839#59874, @machniak wrote:

Indeed. I just noticed that the actual error wasn't an exception. It was PHP Fatal error: Uncaught Error: __clone method called on non-object in /usr/share/roundcubemail/plugins/libcalendaring/lib/libcalendaring_vcalendar.php:633, so to catch it we'd have to catch Throwable, I suppose, I'm not sure.

Still, it makes sense to not skip the entire message, but sync it as it was a normal message, ignoring the fact it has an invitation.

Makes sense, but then we have to try and see if catch Throwable works in here.

Throwable catches that fatal error. Now looking at this I found that we could change the catch in https://git.kolab.org/diffusion/RPK/browse/master/plugins/libcalendaring/lib/libcalendaring_vcalendar.php$158

It seems to me we should:

• Adjust the catch in https://git.kolab.org/diffusion/RPK/browse/master/plugins/libcalendaring/lib/libcalendaring_vcalendar.php (to specifically just ignore a broken itip).
• Adjust all the catches in Sync.php to also catch Throwable
• Add a test that triggers this error to the syncroton testsuite
• Remove the catch in this patch again, so we don't end up with 3 layers potentially catching.

..