[GH-ISSUE #240] SameOrganizerForAllComponentsException

kerem commented

2026-02-25 20:31:13 +03:00

Owner

Originally created by @maybeec on GitHub (Sep 21, 2018).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/240

Latestly, I get an SameOrganizerForAllComponentsException on each synchronization of an existing series, which has not been changed in the last months. The sync is configured with Outlook -> Server only. So there should be no "conflicts" at all.

Exception:

CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '500' ('Internal Server Error'). Message:
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\VObject\ITip\SameOrganizerForAllComponentsException</s:exception>
  <s:message>Every instance of the event must have the same organizer.</s:message>
</d:error>

   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<EnsureSuccessStatusCode>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<ExecuteWebDavRequest>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<ExecuteWebDavRequestAndReturnResponseHeaders>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.DataAccess.CalDavDataAccess.<TryUpdateEntity>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.Implementation.CalDavRepository`1.<TryUpdate>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at CalDavSynchronizer.Implementation.CalDavRepository`1.<TryUpdate>d__16.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.<PerformOperations>d__3.MoveNext()

I am running the latest Nextcloud stable and Outlook 365.

Originally created by @maybeec on GitHub (Sep 21, 2018). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/240 Latestly, I get an SameOrganizerForAllComponentsException on each synchronization of an existing series, which has not been changed in the last months. The sync is configured with Outlook -> Server only. So there should be no "conflicts" at all. Exception: ``` CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '500' ('Internal Server Error'). Message: <?xml version="1.0" encoding="utf-8"?> <d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"> <s:exception>Sabre\VObject\ITip\SameOrganizerForAllComponentsException</s:exception> <s:message>Every instance of the event must have the same organizer.</s:message> </d:error> at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<EnsureSuccessStatusCode>d__10.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<ExecuteWebDavRequest>d__9.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<ExecuteWebDavRequestAndReturnResponseHeaders>d__8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.DataAccess.CalDavDataAccess.<TryUpdateEntity>d__19.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.Implementation.CalDavRepository`1.<TryUpdate>d__16.MoveNext() --- End of stack trace from previous location where exception was thrown --- at CalDavSynchronizer.Implementation.CalDavRepository`1.<TryUpdate>d__16.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.<PerformOperations>d__3.MoveNext() ``` I am running the latest Nextcloud stable and Outlook 365.

kerem closed this issue

2026-02-25 20:31:13 +03:00

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Sep 21, 2018):

And does Outlook show different organizers for some events in the series? Somehow Outlook changes that field in rare circumstances. Check the ics file of that event.

@aluxnimm commented on GitHub (Sep 21, 2018): And does Outlook show different organizers for some events in the series? Somehow Outlook changes that field in rare circumstances. Check the ics file of that event.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Sep 21, 2018):

How can I check the organizers? The appointment is three times a week and runs already over a year ;) Do you know any shortcut rather then trying to go through every occurrence? The organizer maybe changes as of AD update of the organizer contact? I don't think of any other reason, but it maybe there is a way to be stable against such changes.

@maybeec commented on GitHub (Sep 21, 2018): How can I check the organizers? The appointment is three times a week and runs already over a year ;) Do you know any shortcut rather then trying to go through every occurrence? The organizer maybe changes as of AD update of the organizer contact? I don't think of any other reason, but it maybe there is a way to be stable against such changes.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Sep 21, 2018):

Can you export the whole series as ics file and check the organizer field in there?

@aluxnimm commented on GitHub (Sep 21, 2018): Can you export the whole series as ics file and check the organizer field in there?

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Sep 21, 2018):

Server Item:

ORGANIZER;CN="Surname, Forename";SCHEDULE-AGENT=CLIENT:mailto:forename.surname@
 company.com

For any reason, there is a LF after @ (most probably because of line max limit of ics format?) but it is also followed by a single whitespace in the next line! I don't know where this comes from.
However, the local item looks like that:

ORGANIZER;CN="Surname, Forename":mailto:forename.surname@company.com

@maybeec commented on GitHub (Sep 21, 2018): Server Item: ``` ORGANIZER;CN="Surname, Forename";SCHEDULE-AGENT=CLIENT:mailto:forename.surname@ company.com ``` For any reason, there is a LF after @ (most probably because of line max limit of ics format?) but it is also followed by a single whitespace in the next line! I don't know where this comes from. However, the local item looks like that: `ORGANIZER;CN="Surname, Forename":mailto:forename.surname@company.com`

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Sep 21, 2018):

That's the line folding from the ICS format, yes. So it looks the same for every instance in the series? So the only difference is SCHEDULE-AGENT? Try to change that option Set SCHEDULE-AGENGT=CLIENT in the event mapping configuration and see if that changes anything?

@aluxnimm commented on GitHub (Sep 21, 2018): That's the line folding from the ICS format, yes. So it looks the same for every instance in the series? So the only difference is SCHEDULE-AGENT? Try to change that option Set SCHEDULE-AGENGT=CLIENT in the event mapping configuration and see if that changes anything?

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Sep 24, 2018):

I enabled the option Set SCHEDULE-AGENGT=CLIENT, but without success, the error continues occurring on every sync attempt.

@maybeec commented on GitHub (Sep 24, 2018): I enabled the option `Set SCHEDULE-AGENGT=CLIENT`, but without success, the error continues occurring on every sync attempt.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Sep 24, 2018):

And really no different organizer in any of the single events of the recurrence? Can't be, because the error says that "Every instance of the event must have the same organizer."

@aluxnimm commented on GitHub (Sep 24, 2018): And really no different organizer in any of the single events of the recurrence? Can't be, because the error says that "Every instance of the event must have the same organizer."

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Sep 24, 2018):

yes, but how can I assure / check that? Bascially, there are thousands occurrences already. I cannot click through all of them and the exported series ics does not show different organizers.

@maybeec commented on GitHub (Sep 24, 2018): yes, but how can I assure / check that? Bascially, there are thousands occurrences already. I cannot click through all of them and the exported series ics does not show different organizers.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Oct 6, 2018):

Now I start to have it with an additional series appointment as well, which I added about one month ago.
My observation is, that it starts so synchronize occurrences from the future, which have not yet been synchronized as of the synchronization window configured in outlookcaldavsynchronizer. For some reason afterwards added occurrences seem to not match the organizer anymore although I cannot see any change. Here one example of such synchronization:

@maybeec commented on GitHub (Oct 6, 2018): Now I start to have it with an additional series appointment as well, which I added about one month ago. My observation is, that it starts so synchronize occurrences from the future, which have not yet been synchronized as of the synchronization window configured in outlookcaldavsynchronizer. For some reason afterwards added occurrences seem to not match the organizer anymore although I cannot see any change. Here one example of such synchronization: ![grafik](https://user-images.githubusercontent.com/1427255/46569369-5f69b880-c954-11e8-849d-084a0cf12b82.png)

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Oct 8, 2018):

So if you remove the time filtering and use for example WebDAV collection sync instead it doesn't occur?

@aluxnimm commented on GitHub (Oct 8, 2018): So if you remove the time filtering and use for example WebDAV collection sync instead it doesn't occur?

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Oct 9, 2018):

Seems to work, thanks!!!
What is the difference here? I saw, that I am not able anymore to specify a sync range. So will that upload/sync whatever is available?

@maybeec commented on GitHub (Oct 9, 2018): Seems to work, thanks!!! What is the difference here? I saw, that I am not able anymore to specify a sync range. So will that upload/sync whatever is available?

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Oct 9, 2018):

Yes this is a different approach, see https://tools.ietf.org/html/rfc6578
A sync token is used to send only the delta since the last sync, which saves bandwith, but can't be combined with a timerange since this uses a different query.
But we should investigate the organizer and the timerange window in more detail to reproduce your bug.

@aluxnimm commented on GitHub (Oct 9, 2018): Yes this is a different approach, see https://tools.ietf.org/html/rfc6578 A sync token is used to send only the delta since the last sync, which saves bandwith, but can't be combined with a timerange since this uses a different query. But we should investigate the organizer and the timerange window in more detail to reproduce your bug.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Oct 10, 2018):

Now it starts again for one of the appointments to run into the same issue again :(.
The other is fine for now.

@maybeec commented on GitHub (Oct 10, 2018): Now it starts again for one of the appointments to run into the same issue again :(. The other is fine for now.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@nertsch commented on GitHub (Oct 10, 2018):

There must be one exception in Outlook which has a different Organizer.
Finding this out can be done in a few minutes with the following steps:

Open the Synchronization Profiles Dialog
Copy the affected profile and select (Maybe this is done automatically) the copy in the Treeview, to edit it
Make sure that the Mode is "Outlook -> Server (Replicate)"
Set the DAV Url to "file://D:/Temp/Events/"
Close the Dialog by clicking Ok
Make Sure the Directory "D:/Temp/Events/" exists
Click on "Synchronize now"
Find the ics File for the affected appointment (Can be done via search multiple Files with a text editor e.g. Notepad++)
Open the ics-File and check which Organizer is different from the others

br
Gerhard

@nertsch commented on GitHub (Oct 10, 2018): There must be one exception in Outlook which has a different Organizer. Finding this out can be done in a few minutes with the following steps: 1) Open the Synchronization Profiles Dialog 2) Copy the affected profile and select (Maybe this is done automatically) the copy in the Treeview, to edit it 3) Make sure that the Mode is "Outlook -> Server (Replicate)" 4) Set the DAV Url to "file://D:/Temp/Events/" 5) Close the Dialog by clicking Ok 6) Make Sure the Directory "D:/Temp/Events/" exists 7) Click on "Synchronize now" 8) Find the ics File for the affected appointment (Can be done via search multiple Files with a text editor e.g. Notepad++) 9) Open the ics-File and check which Organizer is different from the others br Gerhard

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Oct 11, 2018):

Ok did it.
First: The result is a successful synchronization with the file system with multiple warnings of "invalid email address Uri" for basically multiple appointments.

Second: I searched for the errorneous synchronized series appointment running into errors at my original sync job. I do not really understand the syntax/semantics of ics format, but here is what I observed. There are three different organizers, which are the same person.
1.

ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL
 IENT:

ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL
 IENT:mailto:<mail address>

ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL
 IENT;SCHEDULE-STATUS=1.1:

@maybeec commented on GitHub (Oct 11, 2018): Ok did it. First: The result is a successful synchronization with the file system with multiple warnings of "invalid email address Uri" for basically multiple appointments. Second: I searched for the errorneous synchronized series appointment running into errors at my original sync job. I do not really understand the syntax/semantics of ics format, but here is what I observed. There are three different organizers, which are the same person. 1. ``` ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL IENT: ``` 2. ``` ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL IENT:mailto:<mail address> ``` 3. ``` ORGANIZER;CN="<the persons AD name>";SCHEDULE-AGENT=CL IENT;SCHEDULE-STATUS=1.1: ```

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Nov 29, 2018):

Any news on that? Maybe it's anything related to the Nextcloud 13.0.8 version? It starts with Nextcloud 13.0.7 or Nextcloud 13.0.6 as far as I know. But I am not sure, whether there was an update of outlookcaldavsynchronizer as well in between.

@maybeec commented on GitHub (Nov 29, 2018): Any news on that? Maybe it's anything related to the Nextcloud 13.0.8 version? It starts with Nextcloud 13.0.7 or Nextcloud 13.0.6 as far as I know. But I am not sure, whether there was an update of outlookcaldavsynchronizer as well in between.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Nov 30, 2018):

Seems related to #244

The invalid uri leads to an organizer without email which isn't the same as the original one and that causes the SameOrganizerForAllComponentsException.
So the problem lies in fetching the correct mail from an exchange/AD account in some cases.

Would need an AD test account for that to reproduce.

@aluxnimm commented on GitHub (Nov 30, 2018): Seems related to #244 The invalid uri leads to an organizer without email which isn't the same as the original one and that causes the SameOrganizerForAllComponentsException. So the problem lies in fetching the correct mail from an exchange/AD account in some cases. Would need an AD test account for that to reproduce.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@aluxnimm commented on GitHub (Nov 30, 2018):

Latest commit should fix the exception 8ec7cc43fd
We just force the organizer to be the same.

Still the issue with the invalid mail uris needs to be solved.

@aluxnimm commented on GitHub (Nov 30, 2018): Latest commit should fix the exception 8ec7cc43fd1a79abd446e47baf7aa8155570e7c3 We just force the organizer to be the same. Still the issue with the invalid mail uris needs to be solved.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Dec 6, 2018):

👍 waiting for a release to provide you feedback. Thanks.

@maybeec commented on GitHub (Dec 6, 2018): :+1: waiting for a release to provide you feedback. Thanks.

kerem commented

2026-02-25 20:31:13 +03:00

Author

Owner

@maybeec commented on GitHub (Dec 10, 2018):