Does this actually show as an invitation (with an accept button), but the problem happens when you hit accept? Or, does it happen when you view the invitation?
What is the exact recurrence pattern (and was it an “infinite” recurring pattern)? It might be helpful to simply copy and paste the value from the $ICAL_ORIG_STREAM property on the note and I can try to reproduce. What is the version of the Domino server?
My best guess at this point is that its some pattern like “repeats every M,T,W,T,F,S,S forever”… Since Domino does not have infinite repeat rules, we will truncate such meetings to some finite end date. I know that there was a bug at one point that we were not always truncating at a short enough point which caused problems similar to what you are describing, and I wonder if that is what is happening here?
Is the issue happening only while you try and send invite to Lotus Notes. What if you try and send to another Outlook user / or Gmail etc.
Did you ever encounter the issue while sending single events ?
As I understand the issue is before the invite is actually sent to Lotus Notes user, i.e. in Outlook itself. Would it be possible for you o please send across the logs for further investigation.
Other scenario is when you Cancel, does it work correctly when you reschedule an instance or counter the timings.
Appreciate your time and support here to help us help you better .
Subject: We need a copy of that invitation to continue investigating
Hello Walter,
Nate, Hina and I all work on the same development team (which explains why we’re all responding to you).
We’d like to take a look at the data for that calendar invitation you’re having issues with.
The best way for you to provide the data is to make a selective replica of your mail database and email it to me.
You should be able to send directly to me at the following email address: Frank_Pavelski@notesdev.ibm.com
We don’t need or want everything in your mail database, just the documents that are related to that specific invitation (there may in face be multiple documents related to it)
Subject: Analysis of the data points to SPR IFAY8JKGGK
This iCal was converted by a server running 8.5.2FP4 HF187
This was a repeating meeting that had its recurrence pattern changed by Exchange. In this case Exchange essentially starts with a brand new meeting (they even tell the organizer that any exceptions will be deleted). Domino has a different model here, and to make things consistent for organizer and invitee we literally do that… we delete the meeting and create a new one (with the same identifier).
Unfortunately, there was a defect that caused this deletion and re-creation (of a doc with the same ID) to not replicate well… so issues like you see would happen on say a local replica. That appears to be the cause here.
The fix went into 8.5.4 and can be backported into a server hotfix. The SPR is: IFAY8JKGGK
If you are interested in recovering this single meeting rather than getting a server fix…
You can probably accept it from your home server replica. There still might be ongoing issues with this meeting - so you can try to delete the rep conflict from your local replica… you can see it if you find this meeting in your calendar’s grouped entries view (sorted by date, this would appear as 6/26/2013).