LoadPropertiesForItems silently fails for some items

[neilpendlington]

Using EWS-Api-2.1.1.0.0. In the process of stress testing our service by creating 20 or 30 appointments a day for 7 days in my target calendar, I've found a weird bug that I can't explain. Roughly-speaking, I do the following:

Authentication is via an "ApplicationImpersonation" roled service account.

1. Call service.FindItems() for the WellKnownFolderName.Calendar of the impersonated user, specifying a propertyset of IdOnly.
2. Call service.LoadPropertiesForItems() with an extended property set for the returned FindItemsResults.
3. Iterate each Item and process it ready for display.

Accessing the appointment.Start property, I get an exception "You must load or assign this property before you can read its value." which seems a bit odd, since it's one of the properties I loaded previously.

The problem occurs for the same appointment (250/300) every time (so it's not a service exception-type problem), but only for one appointment in my data-set. Calling appointment.Load() on the specific item resolves the issue and all properties are then populated but it looks like it could be a bug in the call to LoadPropertiesForItems() since all of the other 299 items are resolved and returned correctly.

There's nothing unusual (that I can see) about the appointment that's broken. The test data was created using EWS.

[pasteusernamehere]

Did you ever make any progress on this? I am seeing a similar behavior. I hate to have to call Load on an exception condition.

[davster]

Just curious - are the events that die occurrences of a recurring meeting? And if so, are they exceptions or normal instances?

[pasteusernamehere]

I am getting the exception just trying to access the AppointmentType property so I cannot tell you if it is an occurrence, exception or master.

[pasteusernamehere]

I will check the results from LoadPropertiesForItems and see what is blowing up.

[neilpendlington]

For me they were individual instances of meetings (i.e. no recurrence). Now I've implemented a retry pattern, the problem is masked, but I'm certain that the overall traffic will be slightly increased. Feels like a dirty hack which is never a good thing. I wish I'd grabbed a trace at the time, but this was months ago and I'm certain my test data has gone.

[davster]

Yeah, that is unexpected. I assume that your call to LoadPropertiesForItems includes the start/end time. It would be interesting to see the request/response for that call when you request start and it fails to be returned. Feel free to post again if you hit it again.

[pasteusernamehere]

After interrogating the returned service response collection I found that some of the items returned with an error. Of course trying to access the properties of any of these items in error result in: "You must load or assign this property before you can read its value.". The customer experiencing the issue can now move forward, I am awaiting the logs to understand what the actual error was and how many items were in error.

I take the blame for this one. I should have been reviewing the response collection all along. Ironically none of the code I have found online (including MSDN) using LoadPropertiesForItems ever looks at the method output.

[neilpendlington]

Always a good thing to make your code more robust of course :). My problem was that the same calendar item was returning in an error state (possibly the same you're seeing) every time I did my relatively large query (first 300 items within a date window). I still have a gut feeling that something about that specific appointment was causing the API some problems. Also the fact that it was the 250th appointment raises an eyebrow as that's an awfully round number. I need to allocate a bit if time to revisit this.

[IT-CASADO]

Today i noticed the same problem. Did you find any reason/solution for this?

[neilpendlington]

@IT-CASADO No resolution forthcoming from the API itself (although to be fair, I've not updated it). I was able to reproduce it on some random occasions, but never spotted a pattern. My retry pattern in our code has been in production for a couple of years now and seems to work, albeit a workaround rather than a solution. I don't think this issue has been triaged or looked at by anyone, so you might be better off implementing a similar workaround.

[dneuschaefer-rube]

@IT-CASADO I stumbled across the same issue today. The individual responses in the response collection each contain properties for Result and ErrorCode that should be inspected to ensure there were no errors trying to load the properties. There also is the OverallResult property that can be used as a shortcut to determine whether there are errors inside or not.

Having established that inspecting the collection for errors is necessary despite none of the examples and documentation ever mentioning this, in my specific case it turns out that for one item the request failed with ErrorTimeoutExpired, and subsequent requests failed with ErrorBatchProcessingStopped. So it seems like there is a time limit for processing the requests, and if the collection is large (a few thousand items in my case), it might not be sufficient for all requests. It also seems like upon any error whatsoever, all subsequent requests will fail too.

Your milage may vary, but the important takeaway seems to be the necessity for error handling and retry logic.

[krishnasagarkanigalpula]

@neilpendlington I have tried using retry around my code and it is still failing silently for some items. Do you mind sharing more details on how you are handling the exceptions here?