Changing calendars on an event via Calendar app on macOS and iOS doesn't work
-
I never used to have this problem, but I also rarely have to change calendars after creating an event so the vast majority go to my primary calendar. I've tried a few times in the last week to change a few events (both in past and future) to a different calendar. For some reason it will not keep these changes. I get no errors in the app, but after a short period of time (maybe 10 minutes), the event will revert back to the original calendar it was created in.
If I create new events in the other calendar though to begin with, they are fine. So it seems specific to the changing of the event calendar. I can also rule out the client as the issue (I think) because at first I thought this maybe had to do with me trying this on the beta macOS and iOS versions, but my primary driver is on macOS Catalina and it's always worked but no longer works either, so this doesn't seem specific to the beta use on my side since it also affects the non-beta builds.
Has anyone else experienced this? I'm wanting to see if this is related to the update done in June (as I said - I rarely change the calendar associated to an event so I may have only really noticed this now that I had a few to change), or if it's something very different. Unfortunately I can't restore an app backup to verify because the backups have long lapsed since it was updated back in June.
-
Update: I see this now in my logs, must have missed it before since it's just "INFO" and not an error or anything.
Aug 17 11:43:36 [2020-08-17 18:43:36 +0000] [1/Thread-8143] [INFO] MOVE response status for '/<username>/<CalendarName>/36EAFAB6-0AB0-4EC8-BF4D-555DEC7F1018.ics' in 0.203 seconds: 409 ConflictI suppose that 409 Conflict message may be describing the issue I'm running into. It's thrown on the source calendar, not the target calendar if this makes a difference.
I never noticed this issue until recently, though again I rarely change the calendar on an event, so it may have been this way for a while and I just hadn't noticed. This is why I'm wondering if this had to do at all with the June update of Radicale, though I cannot confirm.
-
Most likely this is a radicale upstream issue. Did you look at their issue tracker for insights?
@nebulon I checked but never found anything related, or at least nothing that seemed related. I can look at filing a ticket in their GitHub for it, just in case.
Is there any possibility for me to downgrade the Radicale version to better test this out though? I suppose I could just copy the current Radicale app in git.cloudron.io and then change the version and deploy as a custom app?
-
Actually you can open a custom crafted url with the app package version like:
https://my.example.com/#/appstore/org.radicale.cloudronapp2?version=2.0.2The version can be obtained from the git repo tags https://git.cloudron.io/cloudron/radicale-app/-/tags
-
Actually you can open a custom crafted url with the app package version like:
https://my.example.com/#/appstore/org.radicale.cloudronapp2?version=2.0.2The version can be obtained from the git repo tags https://git.cloudron.io/cloudron/radicale-app/-/tags
@nebulon said in Changing calendars on an event via Calendar app on macOS and iOS doesn't work:
https://my.example.com/#/appstore/org.radicale.cloudronapp2?version=2.0.2
Oh that's awesome! Just deployed it using 2.0.1 and will test on that. Thank you so much.
-
Actually you can open a custom crafted url with the app package version like:
https://my.example.com/#/appstore/org.radicale.cloudronapp2?version=2.0.2The version can be obtained from the git repo tags https://git.cloudron.io/cloudron/radicale-app/-/tags
@nebulon So interestingly enough in my testing, the issue didn't occur in the old version but also didn't occur in the new version when I upgraded it. So I'm not sure what the root cause is anymore, but presumably not an app issue I guess. May be more to do with my own data somehow, maybe some corruption. I think I'll create a new Radicale on my server and migrate the data and see if that fixes it.
-
Actually you can open a custom crafted url with the app package version like:
https://my.example.com/#/appstore/org.radicale.cloudronapp2?version=2.0.2The version can be obtained from the git repo tags https://git.cloudron.io/cloudron/radicale-app/-/tags
@nebulon Upon further testing there actually was an issue when I tried a new Radicale server, I just didn't see it at first as it wasn't the exact same issue. I no longer receive 409 Conflict messages but 502 Bad Gateway messages whenever a MOVE command is made. I'm not sure why the error has changed, but perhaps it had to do with a sort of "reset" of the data by moving from one Radicale server to another.
I found this in the Radicale GitHub Issues list which is very similar (if not the same):
- https://github.com/Kozea/Radicale/issues/774#issuecomment-365325111
- https://github.com/Kozea/Radicale/issues/842#issuecomment-399745299
- https://github.com/Kozea/Radicale/issues/842#issuecomment-623182954
Here is the exact logs I see (minus the names of the collections):
Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] MOVE request for '/<username>/<sourceCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' received from '<IP>' (forwarded by 172.18.0.1) using 'macOS/11.0 (20A5343i) CalendarAgent/950' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] Successful login: '<username>' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] Unsupported destination address: 'https://calendars.<domain.<tld>/<username>/<destinationCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] MOVE response status for '/d19dotca/<sourceCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' in 0.197 seconds: 502 Bad GatewayLooks like it could have to do with the reverse proxy in front of Radicale. Seems that this may be a mix of how Nginx is configured in front of Radicale and I guess changes in Radicale itself. So this seems to need an update to the Nginx rules, perhaps, with the latest Radicale version.
--
Dustin Dauncey
www.d19.ca -
@nebulon Upon further testing there actually was an issue when I tried a new Radicale server, I just didn't see it at first as it wasn't the exact same issue. I no longer receive 409 Conflict messages but 502 Bad Gateway messages whenever a MOVE command is made. I'm not sure why the error has changed, but perhaps it had to do with a sort of "reset" of the data by moving from one Radicale server to another.
I found this in the Radicale GitHub Issues list which is very similar (if not the same):
- https://github.com/Kozea/Radicale/issues/774#issuecomment-365325111
- https://github.com/Kozea/Radicale/issues/842#issuecomment-399745299
- https://github.com/Kozea/Radicale/issues/842#issuecomment-623182954
Here is the exact logs I see (minus the names of the collections):
Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] MOVE request for '/<username>/<sourceCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' received from '<IP>' (forwarded by 172.18.0.1) using 'macOS/11.0 (20A5343i) CalendarAgent/950' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] Successful login: '<username>' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] Unsupported destination address: 'https://calendars.<domain.<tld>/<username>/<destinationCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' Aug 19 23:07:50 [2020-08-20 06:07:50 +0000] [1/Thread-540] [INFO] MOVE response status for '/d19dotca/<sourceCalendar>/0D990B62-D6CF-4E10-805F-3AB51C21CF21.ics' in 0.197 seconds: 502 Bad GatewayLooks like it could have to do with the reverse proxy in front of Radicale. Seems that this may be a mix of how Nginx is configured in front of Radicale and I guess changes in Radicale itself. So this seems to need an update to the Nginx rules, perhaps, with the latest Radicale version.
-
@nebulon - Any updates on this one by any chance? Seems to be related to both Radicale but also the proxy configuration which I assume is part of the app package details.
-
@nebulon - Just wanted to check in on this. Also a quick update: I tried updating the latest package pushed out today, but the same issue occurs on the 502 Bad Gateway.
@nebulon - Just wanted to check in again as I'm still running into this issue and it's been stale for nearly three weeks now. No rush but just figured I'd make sure this was still on your radar as it's becoming a bigger impact as time goes on. Thank you in advance.
--
Dustin Dauncey
www.d19.ca -
@nebulon - Just wanted to check in again as I'm still running into this issue and it's been stale for nearly three weeks now. No rush but just figured I'd make sure this was still on your radar as it's becoming a bigger impact as time goes on. Thank you in advance.
@nebulon - Just wanted to check in again as this one has been sitting for about 25 days, and it's becoming a bigger issue with my productivity workflow, or more of an annoyance let's say than a real issue but something I'd love too see resolved sooner than later if possible.
-
I was trying to reproduce this now, however I don't have a mac or iOS device and I wasn't able to get a calendar client otherwise to use the MOVE command. They all DELETE/ADD events when moving them from one to another calendar.
Will see if I can get some mac on hand to test this. Just for confirmation, both calendars are within the same radicale instance? Which calendaring apps did you use on mac?
-
I was trying to reproduce this now, however I don't have a mac or iOS device and I wasn't able to get a calendar client otherwise to use the MOVE command. They all DELETE/ADD events when moving them from one to another calendar.
Will see if I can get some mac on hand to test this. Just for confirmation, both calendars are within the same radicale instance? Which calendaring apps did you use on mac?
-
I was trying to reproduce this now, however I don't have a mac or iOS device and I wasn't able to get a calendar client otherwise to use the MOVE command. They all DELETE/ADD events when moving them from one to another calendar.
Will see if I can get some mac on hand to test this. Just for confirmation, both calendars are within the same radicale instance? Which calendaring apps did you use on mac?
-
Ok got access to a macbook, however it works for me:
18:47:20 - [2020-09-15 16:47:20 +0000] [1/Thread-2416] [INFO] GET response status for '/' in 0.000 seconds: 302 Found 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2417] [INFO] MOVE request for '/nebulon/7605fbf0-7bd3-63a0-c8df-e5c4af4f34fd/f9d03e14-303a-4f5d-8c8e-eeaf4cb33690.ics' received from '90.187.246.49' (forwarded by 172.18.0.1) using 'Mac+OS+X/10.14.6 (18G103) CalendarAgent/416.5.1' 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2417] [INFO] Successful login: 'nebulon' 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2417] [INFO] MOVE response status for '/nebulon/7605fbf0-7bd3-63a0-c8df-e5c4af4f34fd/f9d03e14-303a-4f5d-8c8e-eeaf4cb33690.ics' in 0.192 seconds: 201 Created 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2418] [INFO] PROPFIND request for '/nebulon/f1ce483f-5dac-87e1-d2c7-e4706444faab/f9d03e14-303a-4f5d-8c8e-eeaf4cb33690.ics' with depth '0' received from '90.187.246.49' (forwarded by 172.18.0.1) using 'Mac+OS+X/10.14.6 (18G103) CalendarAgent/416.5.1' 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2418] [INFO] Successful login: 'nebulon' 18:47:26 - [2020-09-15 16:47:26 +0000] [1/Thread-2418] [INFO] PROPFIND response status for '/nebulon/f1ce483f-5dac-87e1-d2c7-e4706444faab/f9d03e14-303a-4f5d-8c8e-eeaf4cb33690.ics' with depth '0' in 0.180 seconds: 207 Multi-StatusAre you using calendars of different users?
