Switching from GData Provider for Google Calendar to CalDAV will cause old recurring event notifications to loop endlessly
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(Not tracked)
People
(Reporter: thee.chicago.wolf, Unassigned)
References
Details
(Whiteboard: [regression:?])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
I recently (June 22nd) switched from using GData Provider for Google Calendar to CalDAV for syncing and managing my GMail calenders.
Actual results:
I had over the past 5+ years established recurring events (birthday reminders, special event reminders, weekly, bi-weekly and monthly event reminders, etc.). When CalDAV went out to parse and populate my TB calendars from GMail, it fired off notifications for events that I had already dismissed.
For exampled, in 2015, I set up a yearly reminder for a person's birthday on June 15th. This event had already passed and been dismissed. CalDAV popped up a notification for this event and I could not dismiss it. It had done this for a few other recurring events as well. No amount of clicking on the Dismiss button would make it go away.
The only way I was able to remedy the issue was to 1) Edit All Occurrences for the original recurring event, 2) change the old start date to a new start date with the next occurrence happening at a future date and then 3) Save and Close the event.
Expected results:
Lightning should not fire off new notifications for passed recurring events that have already been dismissed.
Comment 1•4 years ago
|
||
With version 78?
Reporter | ||
Comment 2•4 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #1)
With version 78?
Yup. This is what I saw when I switched from using GData provider to CalDAV on 78.0b4. Not sure if the GData provider addon works differently than CalDAV when it created the original events years ago.
When an event is dismissed, does some "dismissed" flag or boolean True/False get set on the server/calendar side or in the TB profile?
Comment 3•4 years ago
|
||
I don't thing we've seen other reports of this.
But even if we had, it's hard to see how it would be a bug in Thunderbird (CalDAV).
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #3)
I don't thing we've seen other reports of this.
But even if we had, it's hard to see how it would be a bug in Thunderbird (CalDAV).
I understand though I had this issue pop up twice recently. I had a past event that (someone else created and that I accepted) from August 25th pop up the 10th of September quite randomly. I distinctly remember dismissing this event on the 25th when the alarm went off just before the event was to happen.
Another instance was a custom oil change reminder that I'd created years ago and fires off every 7 months. The reminder went off Sept 1st and I couldn't do anything to dismiss or make it go away until I edited/changed the original creation date from years ago and set it to be a new date in the future.
And here comes one to support your premise of it not being a CalDAV issue. I had an event fire off on Sept 13th which I originally created on 9/13/2016. It was a yearly recurring event for a birthday reminder. No issue with that one.
The 1st instance wasn't something I'd created though the second one was. Same for the 3rd reminder. As I stated in the description, any time I had wonkiness it's because these event were created years ago but using GData Provider for Google Cal, not using CalDAV. I can only surmise that something in the way that GData provider did creating those events made CalDAV think these were events that hadn't yet been dismissed. The only thing in common that all of them had were that they were recurring events. But why the 3rd event went off without issue isn't known to me.
I should have some upcoming events that I created years ago set to go off in October. I can only guess that back in TB78 when I opened this bug, there was something amiss. Maybe now that I'm on 81.0b3, it's been fixed or it was something else entirely? I'll close as WFM and if it pops up again, I'll reopen.
Reporter | ||
Comment 5•4 years ago
|
||
Well, as these things go, this alarm that I was talking about the other day just popped up for me at random just a moment ago. I had the presence of mind to CTRL-SHIFT-J to see what error console said about the matter. See attached .txt.
And a PNG for good measure so you don't think I am going making things up. =)
Reporter | ||
Comment 6•4 years ago
|
||
Don't know if there's anything useful here but including it for posterity
I presently have this event up and I cannot dismiss it. Let me know if you want me to try and do something. I'd hate to close it and not get some possibly valuable insight into what might be happening.
Reporter | ||
Comment 7•4 years ago
|
||
Well, and just as mysteriously as it arrived, so too did it mysteriously disappear. I left my desk for 20 minutes to do some task and when I came back and woke my machine, the alarm was gone. I still have the error console open from when I was clicking on Dismiss for this alarm and it gave a PUT and REPORT request.
Reporter | ||
Comment 8•4 years ago
|
||
So, odd as it may seem and impossible as it may be, I am back here again because this alarm from 8/25/2020 just showed it's face again. Is this info from error console of any use? Methinks it's the "item with null recurrenceId!" part that is having a fit.
19:11:43.115 Lightning: recurrenceInfo::addException: item with null recurrenceId! CalRecurrenceInfo.jsm:735
19:11:43.115 Lightning: Exception CalStorageCalendar.jsm:299
columnNumber: 0
data: null
filename: "resource:///modules/CalRecurrenceInfo.jsm"
lineNumber: 736
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
message: ""
name: "NS_ERROR_ILLEGAL_VALUE"
result: 2147942487
stack: "modifyException@resource:///modules/CalRecurrenceInfo.jsm:736:24\n_assureRecurringItemCaches/<@resource:///modules/CalStorageCalendar.jsm:1774:11\n"
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
19:11:43.115 NS_ERROR_ILLEGAL_VALUE: CalRecurrenceInfo.jsm:736
modifyException resource:///modules/CalRecurrenceInfo.jsm:736
_assureRecurringItemCaches resource:///modules/CalStorageCalendar.jsm:1774
AsyncFunctionNext self-hosted:674
Reporter | ||
Comment 9•4 years ago
|
||
Maybe this image will make things more clear?
Description
•