Outlook 2019 - Office 365 Fall 18 Release - Calendar Recurrence Unexpectedly Cached

UPDATE

Our original problem got fixed in v1812. It affected v1808-1811 Outlook 2019 early releases.
April/May 2019 - This problem appears to be back. We are detecting more people hitting this web page. In October, Microsoft fixed this problem with no release note or reference. We can only hope they do so again.

We believe we have detected this issue again, and it affects Tasks with Office 365.

Update 2: So far, we do not find the issue appearing in Outlook v1907.
We are working to track this problem further by tracking effected Outlook versions. If find you are effected, use these step to gather your Outlook version number and the effected data types:

1. Open Outlook, select File in the top left and choose the Office Account option on the left panel.
   
2. Collect the Version listed on the right under About Outlook.
   
3. Verify the type of Folders you are using in Outlook. Open Outlook, click File in the top left and under Account Settings it should list IMAP, POP3 or Exchange.
   

Take this version number, the folder type, the data type effected (Tasks or Calendar), and send us an email to mailto:support@companionlink.com with a subject of "Caching Issues".

Summary

In October 2018 we saw a problem he customer creates a recurring event, and then makes an instance of it at a different time. When we read the recurrence record, Outlook Objects API is passing and exception count of zero instead of the correct number. This causes sync to miss the exception time.

Affects

Office 365 v1808 - A customer has reported this.
Office 365 v1809
Office 2019 Pre-release - We see this inhouse.
MAPI and Standalone folders (PST Files)
NOTE: We have tested on Outlook 365 v1809 and v1808 extensively on other computers, and it is performing as expected. So currently we only have a single computer showing the problem, and that is using a v1811 which is a pre-release Outlook 2019.
Reference: update for Office 365 ProPlus: https://docs.microsoft.com/en-us/officeupdates/update-history-office365-proplus-by-date

Does Not Affect

Exchange folders
Office 365 folders
Outlook 2016 v1807 and earlier. Outlook 2013, 2010, 2007 or earlier

Steps

1. In Calendar, create a timed recurring event for one hour, recurring weekly for three instances.
2. In the middle instance, move it ahead one hour.
3. Edit Primary record in the series, and choose "Entire Series".
4. Make any change. Click Save and Close.
5. Issue: Receive an error trying to save the change "The item cannot be saved because it was changed by another user or in another windows. Do you want to make a copy on the default folder for this item?".

Notes: If Outlook is closed between steps 2 and 3, the edit step 4 works fine (cache is flushed)
Other actions between step 2 and 3 have no effect; changing to contacts and back, adding another calendar, performing a send and receive.

Recovery

After closing Outlook, the cache is flushed and Outlook behaves normally. For customers of our sync products, a reread of the Outlook data will recover any unsynchronized values.

Workaround

For customers who use IMAP folders, instead of using "change this one", add a new event instead.

Discussion

October 1, 2018: First report from end user OL v1808

October 2, 2018: Reproduced inhouse using Outlook 2019 Pre-Release. Found no problems with Exchange folders (OST). Also we have two other computers on v1808 and v1809 that work as expected.

October 3, 2018: Validated our code against published API specification. Examined spec for any note on caching or expectation of data state (none). Examined folder settings to see if there is a close (none).

October 4, 2018: We are checking MAPI interface, to see if this problem is limited to Outlook Objects layer. One workaround would be to automate a reread of all recurring events modified the prior day.

October 5, 2018: Testing whether this is 64-bit only. Unable to confirm. Testing a workaround that may go into place. We are now presuming this is a MIcrosoft API bug. The workaround functions by identifying that the record is being mis-reported which takes one additional function call. In this case it uses an alternative technique to read the Recurrence Exception information. If Microsoft fixes the bug, the new logic will not execute.

October 10, 2018: We have refined the steps to no longer need sync. The Calendar will fail all by itself.
1. Create a recurring event in Outlook Calendar (Weekly, 3 occurrences)
2. Edit the second instance by dragging and dropping to another time.
3. Edit Primary record in the series, and choose "Entire Series".
4. Make any change. Click Save and Close.
5. Issue: Receive an error trying to save the change "The item cannot be saved because it was changed by another user or in another windows. Do you want to make a copy on the default folder for this item?".

Note: If you edit A DIFFERENT instance, make a change, cancel the edit, it prompts do you want to save, and say no. However the pattern commits and step 3-4 will succeed.

Note: Some PCs with the same releases work fine.
Note: Closing Outlook and reopening will clear the error.
Note: 32-bit and 64-bit both exhibit this problem.
Note: Exchange folders - no problem at all - this is standalone folders only ost and pst.
Note: ScanPST does not change the behavior. On the systems affected, this is 100% reproducible.

October 10, 2018: We have scripted a workaround based on what we know. This is a program update to CompanionLink 8 build 2024 and higher. We expect to have this in Beta by Friday Oct 12, and full release early next week.

October 30, 2018: CompanionLink Build 8023 and above has a patch which senses the problem and re-sends the record if needed. We have three field reports, but for various reasons we cannot get access to their PC's to verify. Our inhouse testing is done exclusively on an Outlook Preview version (v1811). We continue in a "wait and see" mode to see if Microsoft will fix the core issue, or if we can find a common setting to force the system to save the recurring record.

November 1, 2018: Our test machine auto updated. It is now using v1812. The problem no longer happens. Microsoft must have found and fixed it!