GNOME Bugzilla – Bug 646164
Varied instances of recurrent meetings lose changes
Last modified: 2011-04-01 05:42:21 UTC
1. Add 'on the web' calendar at http://david.woodhou.se/recurtest.ics 2. Observe that the meeting on 2011-02-24 is an hour later than the others. 3. Observe that the meeting on 2011-02-25 is in a different place. 4. Click the checkbox by the calendar to disable its display. 5. Click the checkbox by the calendar to re-enable its display. 6. Observe that the meeting on 2011-02-24 is still an hour later. 7. Observe that the meeting on 2011-02-25 has reverted to the 'normal' location.
I don't need to disable and re-enable the display to trigger the bug; just scrolling the offending appointment off-screen and back on again is sufficient to trigger the problem. Interestingly, I cannot trigger the bug with local calendars. When I overwrite ~/.local/share/evolution/calendar/system/calendar.ics with the *same* file, it works fine.
Check the order in which they are sent by server and received by client. It depends on the order, if I recall correctly. The master object should be received first, then the detached instances.
The server sends a text file, that you can see at http://david.woodhou.se/recurtest.ics The master appointment *is* first. Perhaps there's some ordering issue when we refetch it from the local cache? The http back end doesn't refetch at all; it checks the ETag hasn't changed and doesn't bother refetching (I think that got into 2.32, didn't it?)
Although it *displays* consistently OK in the local calendar, it doesn't work right when I export it. I right-click on the meeting in my *local* calendar, and choose 'Save as iCalendar...'. It saves a file with the recurring meeting, and *one* modified instance. But as you can see in the original file, there were *two* modified instances. When saving, Evolution only outputs the recurrence where the DTSTART changed. The instance with only LOCATION changed does not appear in the saved file. You should be able to reproduce this by importing the recurtest.ics into your *local* calendar in Evolution, then trying to save it as an ical file. There is oddness here which doesn't need *any* of the 'remote' calendar stores to trigger it.
Oh, wait, it's *more* buggered than that. If you just *import* the recurtest.ics file into your local calendar through the Evolution UI then *none* of the varied meetings show up any different. It isn't until you restart e-calendar-factory that they show up at all.
And when it's in a webcal calendar... Modifying the file and hitting 'refresh' makes it get reloaded and everything looks fine. But I don't even need to scroll it off the screen and back; just scrolling the month display up or down by one week, with my offending appointment always in view, makes it 'revert' to its unmodified form. Milan Crha gave me a clue about ordering, and dbus-monitor seems to suggest that this is indeed the root of the issue. When the webcal calendar is first updated, the master appears first in the signal that's sent by e-calendar-factory: signal sender=:1.819 -> dest=(null destination) serial=799 path=/org/gnome/evolution/dataserver/calendar/CalView/20937/68; interface=org.gnome.evolution.dataserver.calendar.CalView; member=ObjectsAdded array [ string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: LOCATION:foo ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=MO,TU,WE,TH,FR DTSTART;TZID=GMT Standard Time:20110222T103000 DTEND;TZID=GMT Standard Time:20110222T113000 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M END:VALARM END:VEVENT " string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Later recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: RECURRENCE-ID;TZID=GMT Standard Time:20110224T103000 LOCATION:foo ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 DTSTART;TZID=GMT Standard Time:20110224T113000 DTEND;TZID=GMT Standard Time:20110224T123000 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M END:VALARM END:VEVENT " string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Modified recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: RECURRENCE-ID;TZID=GMT Standard Time:20110225T103000 LOCATION:Somewhere different this time ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 DTSTART;TZID=GMT Standard Time:20110225T103000 DTEND;TZID=GMT Standard Time:20110225T113000 BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M END:VALARM END:VEVENT " ]
... but on the later update when I scroll up/down in the calendar view, one of the modified occurrences comes *before* the master, and that's the one which is getting ignored: signal sender=:1.819 -> dest=(null destination) serial=901 path=/org/gnome/evolu tion/dataserver/calendar/CalView/20937/132; interface=org.gnome.evolution.datase rver.calendar.CalView; member=ObjectsAdded array [ string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Modified recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: RECURRENCE-ID;TZID=GMT Standard Time:20110225T103000 LOCATION:Somewhere different this time ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 DTSTART;TZID=GMT Standard Time:20110225T103000 DTEND;TZID=GMT Standard Time:20110225T113000 DTSTAMP:20110331T000024Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M X-EVOLUTION-ALARM-UID: 20110331T000024Z-20937-500-18495-72@macbook.infradead.org END:VALARM END:VEVENT " string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: LOCATION:foo ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 RRULE;X-EVOLUTION-ENDDATE=20110307T103000Z:FREQ=WEEKLY;COUNT=10; BYDAY=MO,TU,WE,TH,FR DTSTART;TZID=GMT Standard Time:20110222T103000 DTEND;TZID=GMT Standard Time:20110222T113000 DTSTAMP:20110331T000024Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M X-EVOLUTION-ALARM-UID: 20110331T000024Z-20937-500-18495-16@macbook.infradead.org END:VALARM END:VEVENT " string "BEGIN:VEVENT UID: AAAZAGRhdmlkLndvb2Rob3VzZUBpbnRlbC5jb20ARgAAAAAAC1lfIzWaQkSVrsfRo+opswcApD vj2OJH5ECvNHezzcsKaQAA9zEKBwAAcVc52Um1MUeWJf5XX1fkGQDuPA8g1AAA SUMMARY:Later recurring appointment X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION property. Removing entire property: RECURRENCE-ID;TZID=GMT Standard Time:20110224T103000 LOCATION:foo ORGANIZER;CN="Woodhouse, David":mailto:david.woodhouse@intel.com SEQUENCE:0 DTSTART;TZID=GMT Standard Time:20110224T113000 DTEND;TZID=GMT Standard Time:20110224T123000 DTSTAMP:20110331T000024Z BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;VALUE=DURATION:-PT15M X-EVOLUTION-ALARM-UID: 20110331T000024Z-20937-500-18495-44@macbook.infradead.org END:VALARM END:VEVENT " ] If ordering matters, should e-calendar-factory be attempting to sort its output?
Breakpoint 11, e_intervaltree_insert (tree=0x959c30 [EIntervalTree], This is what happens as they are *added* to the interval tree. I cannot reconcile the 'start' times with the actual event, except in the case of the 20110225 instance. Where the hell did 1298370600 and 1298547000 come from? start=1298370600, end=2147483647, comp=0x879a00 [ECalComponent]) at e-cal-backend-intervaltree.c:278 278 { (gdb) p e_cal_component_get_recurid_as_string (comp) $20 = (gchar *) 0x0 (gdb) c Continuing. Breakpoint 11, e_intervaltree_insert (tree=0x959c30 [EIntervalTree], start=1298547000, end=2147483647, comp=0x976c00 [ECalComponent]) at e-cal-backend-intervaltree.c:278 278 { (gdb) p e_cal_component_get_recurid_as_string (comp) $21 = (gchar *) 0x998ef0 "20110224T103000" (gdb) c Continuing. Breakpoint 11, e_intervaltree_insert (tree=0x959c30 [EIntervalTree], start=1298629800, end=2147483647, comp=0x95bc80 [ECalComponent]) at e-cal-backend-intervaltree.c:278 278 { (gdb) p e_cal_component_get_recurid_as_string (comp) $22 = (gchar *) 0x879f30 "20110225T103000" (gdb) c Continuing.
Stupid dwmw2; all those are sane. Getting late for me to be doing this... [dwmw2@macbook calendar]$ date --date="20110222 10:30" +%s 1298370600 [dwmw2@macbook calendar]$ date --date="20110224 11:30" +%s 1298547000 [dwmw2@macbook calendar]$ date --date="20110225 10:30" +%s 1298629800 But still they're not coming *out* of the interval tree in the order we'd expect.
Created attachment 184758 [details] [review] fix search output This fixes e_intervaltree_search() to actually return events in the correct order rather than in the order it finds them as it walks the tree. The result is much simpler, too. In 2.32, where I'm testing this, we also have to fix the fact that e_cal_backend_store_get_components_occuring_in_range() will *reverse* the list for us. This was already addressed by commit a2362088f7baf791149bdc919fbda7a0ab14ab52 in 2.9x, although that fix is less efficient than this, because it'll still build the list the wrong way and then reverse it, rather than just getting it right in the first place.
I'm sorry, but you are fixing wrong side, from my point of view. I told you about ECalModel fix I did (though I didn't provide you with a commit id), as it's the place which is order-dependant, but you seem do not listen. ECalModel does things wrong, it may not depend on the order, but it does. Thus commit b1008815f in evolution. I tend to reject your patch.
Ah, sorry, I hadn't properly understood what you were saying. /me looks again... [14:48] <mcrha> also, the evo calendar code (ECalModel, if I recall correctly) depends on order, when master object and detached instances come it. I think I did come changes about it either in a backend or in a e-cal-model OK, that makes more sense to me now. I had understood that the ECalModel depends on the order, but hadn't quite worked out that you had already fixed it in HEAD, and that your fix was to *stop* it depending on the order. Yes, backporting b1008815f looks like it would be a much better fix.
Closing per last two comments, fix included in evolution 2.91.90.