Status updates sent through incorrect IPricingStreams registered actions

As far as I can tell, the backend service appears to be sending incorrect results. For example, in your original post, the first request (.EVAS) is sent using ID: 2. When you send a snapshot request later using ID: 9 for item (0#FDX), the server somehow reported an issue with stream ID: 2. This is the issue. The library simply reacted to the status message, as reported by the server, to deal with a duplicate on ID: 2.

I did update my test to send a snapshot later on to match your original use case, but the correct response came back again.

As I believe the issue is in the backend, I will need to replicate what you have encountered. I don't know the nature of your application, nor the frequency of requests or the volume of items you are requesting. I can spend some time trying to replicate here, but so far no luck.

What I can do is see if there is a way to enable some kind of logs for the streaming service on the desktop - that way we may be able to provide some more insight to report to the backend development team. Let me look into seeing if this is possible.

thanks.

All comments

Thanks for the feedback.

I went through the same use case you provided above, except I did not try the 2nd request hours later, but rather 30 seconds - as a quick test. Does this issue occur randomly or are you able to replicate it every time? Have you tried a simple test where the 2nd request comes shortly after the 1st? I would like to try to replicate this so any additional tests you can do would be helpful.

This is what I did:

var stream1 = Pricing.Definition().Universe(".EVAS")
                                  .GetStream();

stream1.OnRefresh((item, refresh, s) => Console.WriteLine($"Stream 1 Refresh {item}"))
       .OnUpdate((item, update, s) => Console.WriteLine($"Stream 1 Update {item}"))
       .OnStatus((item, status, s) => Console.WriteLine($"Stream 1 Status {item}: {status}"))
       .OnComplete(s => Console.WriteLine("Stream 1 Request Completed."))
       .Open();

System.Threading.Thread.Sleep(30000);

var stream2 = Pricing.Definition().Universe("0#FDX")
                                  .GetStream();

stream2.OnRefresh((item, refresh, s) => Console.WriteLine($"Stream 2 {item}"))
       .OnUpdate((item, update, s) => Console.WriteLine($"Stream 2 Update {item}"))
       .OnStatus((item, status, s) => Console.WriteLine($"Stream 2 Status {item}: {status}"
       .OnComplete(s => Console.WriteLine("Stream 2 Request Completed."))
       .Open();

From the logs:

{
  "ID": 2,
  "Streaming": true,
  "Key": {
    "Name": ".EVAS"
  }
}

{
  "ID": 3,
  "Streaming": true,
  "Key": {
    "Name": "0#FDX"
  }
}

{
  "ID": 3,
  "Type": "Status",
  "Key": {
    "Service": "IDN_RDFNTS_CF",
    "Name": "0#FDX"
  },
  "State": {
    "Stream": "Closed",
    "Data": "Suspect",
    "Code": "NotFound",
    "Text": "The record could not be found"
  }
}

Hi Nick,

thanks for checking this out.

Unfortunately, I would also like to have a clear reproduction case, but unfortunately this appears to happen rather randomly. I could not reproduce this yet on my development machine, only several times with the production app (on a vm).

The repro above was a bit simplified, actually we had several more RICs with an active (streaming) subscription running, happily providing updates until the next morning.Then, a number of streams (in this case with Streaming = False - not sure if this is relevant) where tried to be opened (all for unrecognized symbols). The closed status messages we received where then (imho falsely) distributed among the running streaming subscriptions, rendering them with closed status. Also note that the error message was not like "unknown ticker" but AlreadyOpen / "Cannot request new item on open stream". We have separate stream objects of type IPricingStream that are never reused for later requests.
In which circumstances can the API return such an error?
I am happy to provide as many further details, logs etc. as necessary!

Just for the record, we couldn't reproduce this on the vm today. We got the expected error status responses back through the expected IPricingStream registered action.

We also updated to Eikon 4.0.61017, just in case.

2023-01-26T08:46:06    Debug    Refinitiv.Data.Delivery.Stream.OMMConnection    Stream request "SendMessageAsync": "{
  "ID": 11,
  "Streaming": false,
  "Key": {
    "Name": "0#SDKFKLSDF"
  }
}"
2023-01-26T08:46:06    Debug    Refinitiv.Data.Delivery.Stream.OMMConnection    Status response: "{
  "ID": 11,
  "Type": "Status",
  "Key": {
    "Service": "IDN_FD3",
    "Name": "0#SDKFKLSDF"
  },
  "State": {
    "Stream": "Closed",
    "Data": "Suspect",
    "Code": "NotFound",
    "Text": "The record could not be found"
  }
}"

I did update my test to send a snapshot later on to match your original use case, but the correct response came back again.

thanks.

I'm presently communicating with the backend team and have some follow up/details for you.

Can you provide the API Proxy version as well?
Do you have the ability to use Refinitiv Workspace instead of Eikon - they asked this question

They have found a similar problem in an old version of the API Proxy so they will need to determine if the version you have includes a fix. Also, they did provide instructions to enable logging, but these are instructions for Refinitiv Workspace, not Eikon. I'll wait to hear back from you and report back to the server team.

thanks,

Nick

Hi Nick,

Thank you for your update and thanks for talking to the server team.

Regarding API proxy Version, I'm not fully sure what you mean or where I have to look to find this.

In the Eikon About screen, under apps I found "Proxy (9.61.0.11)". As I mentioned, we updated Eikon the day before yesterday so the logs I reported may have been produced with an older version.

We're using the latest Refinitiv.Data nuget package (1.0.0-beta4).

Unfortunately we have no working Refinitiv Workspace accounts currently (our admin is trying to figure this out for some time now with Refinitiv support).

Our production app is also used by customers that only have Eikon available.

Thanks again, and have a nice weekend,

Ingo

Can you use the following command within a browser to provide the version details the server team is after:

http://localhost:9060/api/status

{"statusCode":"ST_PROXY_READY","version":"3.3.11-eikon4"}