I don't know for sure but the most probable cause of the behavior you describe is that the entity in question is in a changed state when the query data arrive.
You can test for this by checking the
EntityState
of each result entity in your query's success callback and raising the appropriate diagnostic alarm when the entity is in a changed state. I'll bet you confirm my hypothesis.
Breeze query results are merged into cache based on a MergeStrategy
. By default, that strategy is "PreserveChanges" which tells Breeze to ignore incoming values when the target entity has pending changes (that is when its EntityState
is anything other than "Unchanged").
I'm guessing that your queried entities are updated "most of the time" because they are in the "Unchanged" state most of the time. But occasionally something - a user, your app - puts the entity in a changed state and, while that in that state, new values arriving from the server are simply ignored.
This is expected behavior ... it is what "PreserveChanges" means ... and there is no reason for Breeze to throw an exception.
You could change to the MergeStrategy.OverwriteChanges
, either as the query default or on a per-query basis, if that is more appropriate for your use case.
On a personal note, I urge you to make no use whatsoever of the XHR
object. I don't understand why Breeze exposes it in the first place and some Breeze AJAX adapter implementations would be unable to deliver that object. If I have my way, it will disappear from the interface in future Breeze versions. Please treat its presence in the API as unintentional and unsupported.