You may notice when using the Streaming API that while messages are appearing in real time during the session as messages, the final transcript being saved to our backend may have a delayed timestamp when being entered. This creates a discrepancy between the “endedAt”. && “createdAt” config times.
For instance, Speaker 1 says “Welcome to our weekly Tuesday meet-up - I hope you are all refreshed from the weekend and ready to tackle this week’s challenges!” and notes that this is spoken at 8:00AM (EST). This is confirmed by a “endedAt” which reflects “2022-05-17 8:00:00.000 +0000”.
However, they notice that the timing of the message being entered into the Session database is delayed and shows instead something like “2022-05-18 8:04:15.000 +0000” (a delay of 4-minutes and 15-seconds).
This delay can be caused by this process of confirming the Streaming transcript that is being stored in the backend as our “final transcript”. Before it is officially stored in the database as a Message, the final transcript is run through an additional/internal script to create a more accurate translation.
Due to this process applying our additional internal logic/translation as well, you may sometimes indeed notice slight changes in a recorded live transcript, vs a final transcript that is stored for a later GET command.
This delay is not constant, and the above example delay of a “4:15” delay is towards the long end of what this delay should be. However, it is further exacerbated by environment load/usage - so more concurrent calls can increase this delay as more and more messages are being passed through this additional logic.
The delay itself should not be immediate cause for concern - however, if you do notice this delay seem to be constantly at a few minutes (a good benchmark is if it’s constantly delayed 4-5 minutes), or if you notice particularly longer delays that go well above what we’ve mentioned here, please do not hesitate to reach out to our Symbl Support team, and we will be happy to take a look!