When Sentry starts initially, it needs to get a full snapshot from HMS and associate it with a specific notification ID. HMS does not provide any mechanism to get a consistent snapshot with known notification ID. SO Sentry does the following:
1) Read current notification ID_0
2) Obtain full snapshot from HMS
3) Read current notification ID_1
4) If (ID_0 != ID_1) goto 1.
This creates a problem that the process may never converge when there is some constant stream of HMS activity affecting notification IDs. We would like to be able to use a problem that can converge in the presence of updates.
|Fake subtask to deal with jenkins issues||Resolved|