Hi @cdefusco

When you request a SymbolList - in theory it could contain hundreds of thousands of symbols and the initial list (the Refresh) would have to be delivered in multi parts. The delivery of such a long list could take considerable time e.g several minutes.

During this extended time span, it is theoretically possible that some of those symbols (that have been sent in an earlier part) have now expired or no longer match the criteria that represents the Symbol List. In this case the server needs to advise you to remove those symbols for any application level list you are building and so, you may receive an UpdateMsg with a Delete action for that entry. In theory the UpdateMsg could also contain an Update action (if the PROD_PERM field has changed for a previously received symbol).

Also, due to the potentially long timespan for an long Symbol List, there could be a scenario where the server needs to send a StatusMsg because something has gone wrong e.g. if it has to close the SymbolList stream because it has lost upstream connectivity OR a Data Suspect status because there is some other temporary problem with the data / feed.

The difference between a Streaming and non-streaming request, is that with a streaming request, you will continue to receive UpdateMsg and StatusMsg after you receive the complete SymbolList - as and when any of the above scenarios occur. With a non-streaming, once you have received the complete SymbolList, the stream will be close and you will not be informed of any future deletions or updates for symbols that you had previously received.