RecordingMetadata not always found for Conversations

[Nicholas_Heitz]

This may be related to Missing recordings for a conversation, but I experience a slightly different behaviour.

I am attempting to build a deep integration with Genesys platform metadata and voice recordings. In a nutshell, I am experiencing the following perculiarity (Java Genesys Client):

1. search for conversation by date (/api/v2/analytics/conversations/details/query)

2. I follow up for each result found with a call to get all recordingMetadata (api/v2/conversations/{conversationId}/recordingmetadata

3. At this point, on cold start querying for a date in the past with known data, I often find no results. However, if I wait a few seconds and try again, I may find recordingMetadata that I know is there. Or, sometimes, I may not.

4. If I wait some period of time (maybe an hour or so), I can repeat this whole experience.

This doesn't feel like eventually consistent issues....this feels more like the population of an intermediary cache which takes longer than some fixed query timeout. Is there any way to mitigate this, specify an alternate query timeout, or something along these lines? This apparent behaviour makes time based integrations problematic, as "Not Found" doesn't really seem to mean "Not Found".

[tim.smith]

Please open a case with Genesys Cloud Care to investigate the missing data; we do not have access to your data via the forum to perform this type of investigation.

[Nicholas_Heitz]

Hi Tim,

Thank you for responding. I certainly can do that, but the issue isn't one of lost data. The issue is one of apparent non-idempotency in metadata retrieval by conversation. Data that is not there in one request may be there a few seconds later, and then go missing again some time later.
If there is some architectural explanation (like a cache) for this behavior, that may be ok; right now I am struggling to determine the best path to successful 3rd party integration without greater insight into the technology with which I am integrating.