Changing calendars on an event via Calendar app on macOS and iOS doesn't work
-
@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.
-
@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.
-
@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 Gateway
Looks 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 - 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?
-
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-Status
Are you using calendars of different users?
-
The log message of "Unsupported destination address" comes from https://github.com/Kozea/Radicale/blob/7ed51226360212d2958a142d7d193b3bdd0c0e40/radicale/app/move.py#L34 The code there says
to_url.netloc != environ["HTTP_HOST"]
. From a casual reading, could it be that the domain of the calendar is hardcoded somewhere inside radicale? Meaning, if the user moved the radicale app from one location to another, maybe some internal entries are not patched up?This happens for SOGo which I discovered just a couple of days back - https://git.cloudron.io/cloudron/sogo-app/-/issues/19
-
@nebulon & @girish - very interesting. According to the Radicale GitHub it's been an issue for others before and sometimes fixed and sometimes needing the proxy to be modified.
One thing worth mentioning in case this is an issue, though it is released now (or will be very soon so this will be an issue down the road perhaps) is I was running macOS 11 (i.e. the latest one released for September 2020 called Big Sur, running on their public beta builds earlier). So maybe there's something different now in how their Calendar app handles changes to calendars - no longer doing a DELETE+ADD but a MOVE now - although it's odd because it wasn't an issue earlier in the beta builds and I think either way they're still doing it correctly (just maybe different) as a MOVE method is a valid command to Radicale. Though this may explain why it works for you and not me, as we're running different macOS versions.
You may be on to something though about that part of the code in their GitHub project with "to_url.netloc != environ["HTTP_HOST"]". Never seen that before and it's never been an issue before to my knowledge. Any ideas where that might be stored though? Is that something I need to change in my environment or is that more of an app thing? I was able to reproduce it before on a brand new Radicale deployment, so I assume this isn't something I have control over?
-
Seems the HTTP_HOST value is set too in the proxy according to the docs: https://github.com/Kozea/Radicale/blob/9d25cc6c0ae6fa72bd6c57b76cbd25f1fddedbc0/DOCUMENTATION.md
I assume it's using that set in the nginx reverse proxy in it's comparison logic for the MOVE command? Though still doesn't necessarily explain why it works for you guys though, as I assume that same value would be set anyways, it's the hostname of the app after all, isn't it? -
I don't think the macOS version is the issue here, since I also see the MOVE command being used (but in my case successfully) if I move events between calendars of the same user.
In your case, did you ever move that radicale app instance from one domain/subdomain to another?
-
@nebulon I don't believe I have, I think I've added additional domains though. Basically the subdomain for the Radicale instance is "dav" and to my knowledge always has been. However more recently I added in a couple of additional locations like "calendars" and "contacts", etc.
I think what I'll try next is deploy a fresh Radicale instance but specifically only with one location, and making sure the Calendar app uses that one alone and see if I can reproduce it. I had tried before but I think I had also added in additional domains again, so I'll try again with just one, because maybe that's related to the host name check in the Radicale code?