Hello @didier.nadeau,

I would not approach the application's actions in this situation as "should".

Rather, application "can attempt" to recover, and in these cases it is preferable, if there is such option, to try to recover with another service, on another server, as this infra endpoint does not appear to be in a healthy state, at the moment.

I would attempt another, upon receipt, if available, or wait for some amount of time, configurable, and then try to recover the same, if it is the only available.

Any condition that can be causing the disruption is expected to clear, the question is time.

I would also, if the infrastructure is hosted, or cloud-based, confirm with service alerts on my.refinitiv.com if there is any maintenance or outage in pogress. If the infra is deployed, maintained by your organization's market data team, I would try to contact local market data admin/group for more info.

Thanks for your reply @zoya.farberov.

However I'm still unsure how to handle this. It seems error 1 (Request for blocked delayed RIC is not allowed.Unable to create MQOSStreamItem stream.) means the requested ric is invalid, while error 2 (F27: Server is pending shutdown. Please retry.Unable to create MQOSStreamItem stream.) implies an issue on Refinitiv's side.

Therefore I would expect the application could resent the request in case 2 to get data, but it shouldn't in case 1 as the requested ric is invalid. Is this expectation correct ? If so, how can I handle this programatically using the error codes (not parsing the error message string) ?

Thanks

Hello @didier.nadeau,

Have you observed all these errors close within each other in time, most likely part of the same failure, or at separate times?

The first status looks different from invalid RIC, which is "The record could not be found", one can test this by requesting an invalid RIC. It appears to be one of the RICs blocked for either requesting user or a group of users that includes the requesting user, at the infra level.

These are not commonly encountered statuses, however they have resulted in stream being closed, there must be an underlying cause that may be very brief, or may take time to resolve, which is why I would wait before trying again, as a strategy, for all 3.

The underlying issue should eventually clear on the infra level and the consumer should be able to re-request. However, I would not re-attempt immediately, for that reason.

Would like to offer more info, so you can make up your own best strategy.

F-numbered errors originate with infrastructure directly, Advanced Data Hub (ADH). ADH Installation Guide on my.refinitiv contains the descriptions for many of them, however, not all, as different versions of the infra may introduce specific letter+number errors.

All 3 statuses look to me (am a developer, and an engineer may have a deeper insight into this) to have originated with ADH, the first being blocked item (can be expected, will not be allowed to be opened as long as it is blocked), second being ADH cache at capacity (looking to pre-empt a currently open, depending on the mechanism, usually current item will be pre-empted) and only the last F27, qualifies as error, server will refuse requests if it's in the process of a shutdown.

I hope this info is useful, and will enable you to make the best decisions, based also on your requirements.