Option to discard bad/invalid pending edits

[Terrance]

I've just had to unpick a recurrence edit which resulted in the server rejecting it (see Etar-Group/Etar-Calendar#1672; looks like the same issue as #66 but in Etar).

As part of this, I wanted to just discard the edit and refetch from the server, though I couldn't see an easy way of doing this, short of unsyncing and resyncing the calendar (which is what I did in the end, and it took a while as a result). I tried editing the event on another device, as well as manually bumping its DTSTAMP, so that the server had a newer version of the event, but DAVx5 seemed to continue trying and failing to upload its copy instead.

I'm aware this is ultimately an issue with the iCalendar client, but it would be useful to have an escape hatch at this layer if something like this does go wrong and blocks syncing of an event (or worse).

[rfc2822]

I tried editing the event on another device, as well as manually bumping its DTSTAMP, so that the server had a newer version of the event, but DAVx5 seemed to continue trying and failing to upload its copy instead.

That should work. DAVx⁵ always lets the server win and if there's a new version on the server, DAVx⁵ won't overwrite it with the local modified version, but download it from the server again.

If it did not in your case, I'd need to have a look at the verbose logs to tell why (probably the server didn't update the ETag on the changes).

---

About the original problem:

I'm aware this is ultimately an issue with the iCalendar client, but it would be useful to have an escape hatch at this layer if something like this does go wrong and blocks syncing of an event (or worse).

Do you have a suggestion how this could work?

[Terrance]

I thought I'd grabbed the debug info at the time but apparently not. 🙁 The server (Radicale) uses flat file storage so I just edited the file on disk, which is supposedly supported and does get picked up, but it's possible the server needs a restart to properly reindex and refresh ETags from disk. If it happens again then I'll try and grab some more info.

As for the escape hatch: failing items currently generate a notification with the error summary (in this case, 400 Bad Request) and a View Item action that shows the debug screen -- UI-wise I'd imagine the easiest thing would be a second Discard Changes action to fetch that individual item again from the server and replace any local state?