handling "zero" mergeToGroup value
Using the decoding method suggested in https://community.developers.refinitiv.com/answers/47439/view.html , I found that our consumer app receives mergedToGroup updates with "0" values after CLOSE_RECOVER groupId state is received. Is "0" a valid value for mergeToGroup or should I ignore them?
I assume that you are connecting to TREP. TREP manages the groupID and it will send mergeToGroup with zero value after the service is down.
<updateMsg domainType="RSSL_DMT_SOURCE" streamId="2" containerType="RSSL_DT_MAP" flags="0xC0 (RSSL_UPMF_DO_NOT_CACHE|RSSL_UPMF_DO_NOT_CONFLATE)" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="51">
<dataBody>
<map flags="0x0" countHint="0" keyPrimitiveType="RSSL_DT_UINT" containerType="RSSL_DT_FILTER_LIST" >
<mapEntry flags="0x0" action="RSSL_MPEA_UPDATE_ENTRY" key="4915" >
<filterList containerType="RSSL_DT_ELEMENT_LIST" countHint="0" flags="0x0">
<filterEntry id="3" action="RSSL_FTEA_SET_ENTRY" flags="0x0" containerType="RSSL_DT_ELEMENT_LIST">
<elementList flags="0x8 (RSSL_ELF_HAS_STANDARD_DATA)">
<elementEntry name="Group" dataType="RSSL_DT_BUFFER" data="2"/>
<elementEntry name="MergedToGroup" dataType="RSSL_DT_BUFFER" data="0"/>
</elementList>
</filterEntry>
</filterList>
</mapEntry>
</map>
</dataBody>
</updateMsg>
After the service is up, the application will get a new groupID in the item's refresh message.
Therefore, it could be the default groupID managed by TREP. You can contact the TREP support team through my.refinitiv.com for more information.
Can someone please answer the question or ask additional questions if the question is not clear?