We are working on Genesys Cloud integration enhancement to use Event Bridge instead of Notification Service to get agent states.
We get the current agent's state while he is on a call by listening to 'v2.analytics.conversation.{id}.metrics' using Event Bridge. There is a scenario where we see some inconsistent behaviour from Genesys and would like confirmation or clarification if that is a bug or not?
The scenario is agent is on a call with a client, and wants to make a consult call. When the consult call is initiated we receive 'nConsult' metric event which contains 'metricDate', and it seems valid (matches with the timestamp, when event occurred). But after the consult call is finished, if agent decides to make the second consult call - it appears that the second 'nConsult' metric event has a 'metricDate' which does not correspond to the real metric event timestamp (the difference could be around 10-20 seconds in the past), making it impossible to use the 'metricDate' field as the event timestamp.
So there is a question: is that a bug on Genesys side? Can we rely on the metricDate of other metric events? Does it represent the real event timestamp?
Example:
1st nConsult event {"metric":"nConsult","metricDate":"2023-09-12T11:21:38.912+00:00"}
actual event timestamp: "2023-09-12T11:21:39.145+00:00"
2nd nConsult event {"metric":"nConsult","metricDate":"2023-09-12T11:21:41.295+00:00"}
actual event timestamp: "2023-09-12T11:22:06.169+00:00"