starred/outlookcaldavsynchronizer

Fork 0

mirror of https://github.com/aluxnimm/outlookcaldavsynchronizer.git synced 2026-04-26 03:25:48 +03:00

[GH-ISSUE #286] Status code 412 ('Precondition Failed') not handled properly, disappearing events after sync #746

New issue

Closed

opened 2026-03-01 17:41:18 +03:00 by kerem · 4 comments

kerem commented

2026-03-01 17:41:18 +03:00

Owner

Originally created by @heinrich-ulbricht on GitHub (Oct 5, 2020).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/286

I synchronize Outlook with a Synology NAS. Generally speaking this works fine, appointments get created. I'm replicating from Outlook to the server.

Observed behavior
My synchronization reports show errors on a regular basis:

CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '412' ('Precondition Failed')

This sometimes seems to break synchronization of appointments with the Synology NAS. Events are missing or disappearing from my Synology NAS calendar.

Full raw error message for a recently created test appointment:

<?xml version="1.0" encoding="utf-16"?>
<SynchronizationReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ProfileName>Calendar</ProfileName>
  <ProfileId>2c85a681-2dfe-462a-beef-f5e68b86f4c6</ProfileId>
  <StartTime>2020-10-05T13:56:43.8683433Z</StartTime>
  <ADelta>Unchanged: 0 , Added: 1 , Deleted 0 ,  Changed 1</ADelta>
  <BDelta>Unchanged: 1 , Added: 0 , Deleted 0 ,  Changed 0</BDelta>
  <AJobsInfo>Create 0 , Update 0 , Delete 0</AJobsInfo>
  <BJobsInfo>Create 1 , Update 1 , Delete 0</BJobsInfo>
  <LoadErrors />
  <EntitySynchronizationReports>
    <EntitySynchronizationReport>
      <MappingErrors />
      <MappingWarnings />
      <AId>00000000B3194B3AD5A1F94E96020<snip>9AB32190000</AId>
      <ADisplayName>test</ADisplayName>
      <ExceptionThatLeadToAbortion>CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '412' ('Precondition Failed'). Message:
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;error xmlns="DAV:"&gt;
  &lt;if-none-match/&gt;Existing resource matches "If-None-Match" header - not accepted.
&lt;/error&gt;
   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.&lt;EnsureSuccessStatusCode&gt;d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.&lt;ExecuteWebDavRequest&gt;d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.&lt;ExecuteWebDavRequestAndReturnResponseHeaders&gt;d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.DataAccess.CalDavDataAccess.&lt;CreateNewEntity&gt;d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.Implementation.CalDavRepository`1.&lt;Create&gt;d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.&lt;PerformOperations&gt;d__3.MoveNext()</ExceptionThatLeadToAbortion>
      <Operation>CreateInB</Operation>
    </EntitySynchronizationReport>
  </EntitySynchronizationReports>
  <ConsiderExceptionThatLeadToAbortionAsWarning>false</ConsiderExceptionThatLeadToAbortionAsWarning>
  <Duration>00:00:03.4672274</Duration>
</SynchronizationReport>

Looking at the log it seems that CalDav Synchronizer creates the appointment. Then tries to create it again. So this error might be the correct response by the server!

Expected behavior
I expect those errors to not be present or to not interrupt synchronization.

How to reproduce
For me it's enough to just keep CalDav Synchronizer running and doing its thing. The errors will show up regularly. But also creating a test appointment and triggering a manual sync triggered the error.

I searched the web for similar reports in combination with a Synology NAS but found nothing useful. Not sure if this is a general error about handling 412s or something specific to my setup.

Possible solution?
Maybe CalDav Synchronizer could handle the 412 as "already exists" and count it as success? Or add a debug configuration to handle 412 like 304 or to ignore it.

Looking at the documentation of if-none-match:

When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified). For methods that apply server-side changes, the status code 412 (Precondition Failed) is used.

(The real error might be that CalDav Synchronizer wrongly tries to create an already existing appointment. Because according to the debug log it does exactly that.)

Versions
CalDav Synchronizer Version is 3.8.2.0
Windows 10 Pro
Outlook for Microsoft 365 MSO (16.0.13127.20402) 64-bit

Originally created by @heinrich-ulbricht on GitHub (Oct 5, 2020). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/286 I synchronize Outlook with a Synology NAS. Generally speaking this works fine, appointments get created. I'm replicating from Outlook to the server. **Observed behavior** My synchronization reports show errors on a regular basis: > CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '412' ('Precondition Failed') This sometimes seems to break synchronization of appointments with the Synology NAS. Events are missing or disappearing from my Synology NAS calendar. Full raw error message for a recently created test appointment: ``` <?xml version="1.0" encoding="utf-16"?> <SynchronizationReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ProfileName>Calendar</ProfileName> <ProfileId>2c85a681-2dfe-462a-beef-f5e68b86f4c6</ProfileId> <StartTime>2020-10-05T13:56:43.8683433Z</StartTime> <ADelta>Unchanged: 0 , Added: 1 , Deleted 0 , Changed 1</ADelta> <BDelta>Unchanged: 1 , Added: 0 , Deleted 0 , Changed 0</BDelta> <AJobsInfo>Create 0 , Update 0 , Delete 0</AJobsInfo> <BJobsInfo>Create 1 , Update 1 , Delete 0</BJobsInfo> <LoadErrors /> <EntitySynchronizationReports> <EntitySynchronizationReport> <MappingErrors /> <MappingWarnings /> <AId>00000000B3194B3AD5A1F94E96020<snip>9AB32190000</AId> <ADisplayName>test</ADisplayName> <ExceptionThatLeadToAbortion>CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '412' ('Precondition Failed'). Message: <?xml version="1.0" encoding="utf-8" ?> <error xmlns="DAV:"> <if-none-match/>Existing resource matches "If-None-Match" header - not accepted. </error> at CalDavSynchronizer.DataAccess.HttpClientBasedClient.WebDavClient.<EnsureSuccessStatusCode>d__10.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(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.ExceptionServices.ExceptionDispatchInfo.Throw() 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.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.DataAccess.CalDavDataAccess.<CreateNewEntity>d__27.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.Implementation.CalDavRepository`1.<Create>d__17.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.<PerformOperations>d__3.MoveNext()</ExceptionThatLeadToAbortion> <Operation>CreateInB</Operation> </EntitySynchronizationReport> </EntitySynchronizationReports> <ConsiderExceptionThatLeadToAbortionAsWarning>false</ConsiderExceptionThatLeadToAbortionAsWarning> <Duration>00:00:03.4672274</Duration> </SynchronizationReport> ``` Looking at the log it seems that CalDav Synchronizer creates the appointment. Then tries to create it again. So this error might be the correct response by the server! **Expected behavior** I expect those errors to not be present or to not interrupt synchronization. **How to reproduce** For me it's enough to just keep CalDav Synchronizer running and doing its thing. The errors will show up regularly. But also creating a test appointment and triggering a manual sync triggered the error. I searched the web for similar reports in combination with a Synology NAS but found nothing useful. Not sure if this is a general error about handling 412s or something specific to my setup. **Possible solution?** Maybe CalDav Synchronizer could handle the 412 as "already exists" and count it as success? Or add a debug configuration to handle 412 like 304 or to ignore it. Looking at the documentation of [if-none-match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match): > When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified). **For methods that apply server-side changes, the status code 412 (Precondition Failed) is used**. (The real error might be that CalDav Synchronizer wrongly tries to create an already existing appointment. Because according to the debug log it does exactly that.) **Versions** CalDav Synchronizer Version is 3.8.2.0 Windows 10 Pro Outlook for Microsoft 365 MSO (16.0.13127.20402) 64-bit

kerem closed this issue

2026-03-01 17:41:18 +03:00

kerem commented

2026-03-01 17:41:18 +03:00

Author

Owner

@heinrich-ulbricht commented on GitHub (Oct 5, 2020):

I can trigger the error by:

creating an appointment - the auto-sync kicks in and creates the remote appointment
invoking a manual synchronization

This will get me a 412 response code for the appointment.

@heinrich-ulbricht commented on GitHub (Oct 5, 2020): I can trigger the error by: 1. creating an appointment - the auto-sync kicks in and creates the remote appointment 2. invoking a manual synchronization This will get me a 412 response code for the appointment.

kerem commented

2026-03-01 17:41:19 +03:00

Author

Owner

@heinrich-ulbricht commented on GitHub (Oct 6, 2020):

Additional thoughts: the configured repository URL is <server>/caldav/<etc>. This is handled well by the Synology NAS, internally it rewrites this to <server>/caldav.php/<etc>. While debugging I saw that this URL (or parts of it) is used as ID in some places and I'm wondering if this might cause problems. I saw both versions being handled by the code and maybe this breaks some change/duplicate detections?

After writing this I saw that the log even contains a message regarding this:

DEBUG 2020-10-05 15:56:43,877 [ VSTA_Main] Synchronizer.DataAccess.WebDavDataAccess . AlignServerUrl                 - Aligned decoded resource uri path '/caldav.php/user/home/' different from server uri '/caldav/user/home/'

Is this handled well?

@heinrich-ulbricht commented on GitHub (Oct 6, 2020): Additional thoughts: the configured repository URL is `<server>/caldav/<etc>`. This is handled well by the Synology NAS, internally it rewrites this to `<server>/caldav.php/<etc>`. While debugging I saw that this URL (or parts of it) is used as ID in some places and I'm wondering if this might cause problems. I saw both versions being handled by the code and maybe this breaks some change/duplicate detections? After writing this I saw that the log even contains a message regarding this: ``` DEBUG 2020-10-05 15:56:43,877 [ VSTA_Main] Synchronizer.DataAccess.WebDavDataAccess . AlignServerUrl - Aligned decoded resource uri path '/caldav.php/user/home/' different from server uri '/caldav/user/home/' ``` Is this handled well?

kerem commented

2026-03-01 17:41:19 +03:00

Author

Owner

@heinrich-ulbricht commented on GitHub (Oct 6, 2020):

It seems the problems are gone after changing the repository URL from https:///caldav/user/home/ to https:///caldav.php/user/home/ (note the added .php).

While surfing the web I noticed 412 HTTP response codes in combination with other systems. Maybe such URL rewriting is the cause there as well.

I'll monitor this for a while. So far the current situation looks promising.

@heinrich-ulbricht commented on GitHub (Oct 6, 2020): It seems the problems are gone after changing the repository URL from _https://<synology-nas>/caldav/user/home/_ to _https://<synology-nas>/caldav.php/user/home/_ (note the added **.php**). While surfing the web I noticed 412 HTTP response codes in combination with other systems. Maybe such URL rewriting is the cause there as well. I'll monitor this for a while. So far the current situation looks promising.

kerem commented

2026-03-01 17:41:19 +03:00

Author

Owner

@heinrich-ulbricht commented on GitHub (Oct 6, 2020):

No errors anymore. Problem solved.

@heinrich-ulbricht commented on GitHub (Oct 6, 2020): No errors anymore. Problem solved.