Conversation entry timestamps shifting 1-2 seconds after creation | Community
Skip to main content

Conversation entry timestamps shifting 1-2 seconds after creation

  • December 1, 2022
  • 5 replies
  • 0 views
Support22

Our support plugin uses the ticket.conversation.changed listener to detect new messages. The array of message entries does not contain any unique identifier data, other than text and timestamps. Text alone cannot be used as an identifier, and the timestamps are intermittently unstable. After posting an agent reply, the timestamp we record in our plugin remains consistent around 75% of the time. Intermittently, this timestamp will shift forward anywhere from 0-2 seconds, sometimes more than two seconds. This causes our app's expected behavior to break, since the timestamp we have recorded no longer exists in the array of entries.

I am wondering if there is a cause for the shifting timestamps, I have not observed a direct cause. Including stable message IDs in the ticket.conversation array of entries would allow developers to not have to rely on unstable timestamps to uniquely identify messages.

These are timestamps recorded on creation of two conversation entries from our plugin

These are the timestamps for the same two entries logged from Zendesk after the page is reloaded

Thanks!

      5 replies

      C
      Hi Jana,
       
      Are you noticing duplicate or missing messages returned?  Also, can you share some more info about how your app uses the messages?  I'd like to gather a bit more context around the app behavior that is breaking and how it depends on uniquely identifying individual messages.
      Support22
      • Support22
      • Author
      • December 5, 2022

      Yes, there are sometimes duplicate agent reply messages that disappear after reload.

      Our app is a translation plugin that displays the comments, translations, and the relationship between the two. When a message is translated, we store the timestamp from the source comment and the translation in our API so we can properly match the translations to the correct source comments. So, when there is a discrepancy between the timestamps stored in Zendesk and the timestamps stored in our API, the relationship between the source and translation breaks. Ideally, our app needs a stable piece of identifying data from each comment that would be supported in chat, messaging, and tickets.

      C
      Hi Jana,
       
      Thanks for the context.  The messages in the ticket conversation are returned in the order that they were added.  Have you tested using the index of the message within the array to identify an individual message?  Also when doing so, does your translation service still observe duplicates?
       
       
      Support22
      • Support22
      • Author
      • December 7, 2022

      Thank you. Unfortunately using indexes would not work in our application because not every translation is returned immediately, sometimes other messages are created/sent before a translation is returned. We need a way to store relationships between comments, and indexes alone would not be stable or reliable enough.

      C
      Hi Jana,
       
      Once the conversation ends, a transcript is added to the ticket.  The transcript is added as a ticket comment with its own ID that you may access via REST API.  If possible, the cleanest approach might be to separate into two different functional tasks:
       
      • Translation for quick use by the agent while the conversation is active
      • Storage of translated messages from transcript once the conversation ends to allow for additional app features that don't fit as well while the conversation is live
       
      We've recently added the ability to fire a trigger once the transcript is added to the ticket.  You can connect this trigger to a webhook to automatically notify your translation service when a transcript is added.
       
       
      Terms & ConditionsCookie settingsAccessibility statement