Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Traveler causing replication/save conflict for invitations accepted in Notes client

Daniel Nashed  19 February 2019 15:29:54

Traveler causing replication/save conflict for invitations accepted in Notes client

This issue can occur for normal invitations and also with *.ICS files that you add to your calendar.

We found out that this is a timing issue between the user interaction and the background processing of the Traveler server.


There are two different scenarios:


a.) Accept an invitation (technically a "notice" document which when accepted is saved as an "appointment".


b.) An *.ICS file which is launched and turned into a "notice" which is than when accepted saved as an "appointment"


In both cases it can happen that the so called meeting ghosting adds a field "ILNT_GhostUNID" into the "notice" document causing a replication/save conflict when the user interacts at the same time.

Calendar ghosting is used to display the invitation as a not yet accepted meeting in a calendar.


Right now the only way to safely avoid this issue is to disable Calendar Ghosting functionality on the Traveler side.

The functionality on the Notes side will continue to work. This just disables the Traveler functionality.


We got the following notes.ini settings for disabling the Ghosting Calendar functionality. You need to disable both!


My support ticket is still open and I will update this blog entry when I get a SPR.


-- Daniel


NTS_IOS_CALENDAR_INITIAL_GHOST=false


Traveler will ghost meeting updates to the Apple iOS Calendar application's calendar even when the initial invitation has not been accepted yet. Ghosting enables you to see the original invitation and schedule change correctly. Applies to iOS 9 or later

The default is true.



NTS_CALENDAR_GHOSTING_SYNCML=false


Allows meeting invitations to be "ghosted" on the Verse mobile client calendar (iOS and Android). Ghosting enables you to see the original invitation and schedule change correctly.

The default is true.



If you are interested in what happens see the details below:


a.)


The user opens the invitation ("notice" document) before the Traveler processes the "notice".

While the user has the invitation open Traveler updates the document and adds the "ILNT_GhostUNID" to it.

The user accepts the meeting and saves turns the "notice" into an "appointment", which causes the replication/save conflict


--> The conflict occurs when the user opens the invitation before the Traveler has processed the invitation


b.)


When an user opens an *.ICS attachment a new "notice" document will be created in the user mail-file an the document will be opened directly in the client.

Meanwhile the Traveler server will see the document and add the "ILNT_GhostUNID".

Afterwards the user accepts the meeting and updates the "notice" to turn it into an "appointment"


--> The conflict occurs when the user is taking "too long" to accept the meeting.


But in this scenario the delay needed is quite short and you have to be lucky!
It will happen most of the time because the Traveler server has a subscription into the mail-files with the notification API and by default checks for new data every 3 seconds.

The only work-around from user side that would be save is:


- Launch the *.ICS File to turn it into a notice

- close the document and wait a while until Traveler processed the document

- re-open it to accept it


We first ran into scenario a.) but it turned out scenario b.) is the one that causes more issues because you have to be either very fast to accept the invitation before Traveler processes the document or use the described work-around.


Replication/save conflicts in calendar documents can cause that appointments are not shown in the calendar even you accepted them and you cannot accept them again because it already exists with the same ApptUNID (internal ID used for identifying an appointment).


Archives


  • [IBM Lotus Domino]
  • [Domino on Linux]
  • [Nash!Com]
  • [Daniel Nashed]