Open peppy opened 3 weeks ago
➤ PM Bot commented:
Jira ticket: RNET-1165
Just to clarify, the behavior you're observing is that you get the initial notification that already has changes
populated? I agree that's likely not ideal as it makes it difficult to determine whether you need to setup the initial UI or mutate the existing containers.
@nirinchev precisely, yes. we're now working around this in a very simple fashion, which looks to be working well.
Sorry for getting back slowly on this - this is indeed a bug in the .NET SDK and the workaround you have is valid. We'll need to implement something similar.
What happened?
I have been tracking an occasional bug where our subscription handling was dying on index-out-of-range exceptions. It turns out that in a heavy usage scenario with ongoing modifications, the callback coalesces multiple events:
Unfortunately this includes the initial notification.
This is a puzzling API decision – as a user are you supposed to always create a tracking boolean to know when the initial population arrives? It seems that if you don't do this, it would not be possible to use the subscription for displaying in a view correctly (as you can't tell the difference between an empty list or yet-to-be-initially-populated list).
We have been writing change handling like this:
but we'd instead need to do something like this for correct handling:
It feels a bit counterintuitive to have to retain an
isPopulated
trackingbool
for these subscriptions.Also of note, the xmldoc on
NotificationCallbackDelegate
implies the initial callback will always be null:Version
12.2.0
What Atlas Services are you using?
Local Database only
What type of application is this?
Other
Client OS and version
macOS (but all)