DCR: Timestamping both bot and user activities

[compulim]

Issue

(Including @swagatmishra2007. We talked about this offline. But I believe this is less likely to require a fix on the channel side.)

This is a problem because the combination of SDK and Direct Line channel. It may not apply to other channels.

Client = DLJS, Web Chat, or any ABS clients

Today's characteristics:

• Activities could arrive at the client at pseudo-random order
  • Given U1 is the activity from user, B1 and B2 is the first and second activity from bot
  • Sending U1 to the bot, the bot will reply with B1 and B2
  • The order of activity arrive at the client, most of the time, it is: B1, B2, U1
    • User is expected to perceive it as U1, B1, B2, instead.
  • Sometimes, it can be a bit random due to polling
  • To support transcript-based client, the client need some knowledge to reorder the activities
• Direct Line channel will put a timestamp on the user message and echo it back to the client
  • This is considered as read receipt
• Web Chat use this timestamp to sort messages

The problem is:

• The timestamp for bot activity can be random because Direct Line channel is on a server farm, B1 and B2 could have a timestamp that would reorder into B2 then B1
• Same for user activity
• We cannot timestamp on the client side because the client has no knowledge of the real order of the activities
  • We know B1 and B2 is a reply of U1
  • We don't know B1 is before B2

Proposed change

We could timestamp both bot and user activities on bot side. Since U1, B1, B2 should be processed on the same box. This will make the timestamp for all these activities more "trueful".

For proactive messages, I think it is fair to say the timestamp may be slightly off because of its distributed nature. Given B3P is a proactive message, it will have very slight chance to make B3P chronologically appear before B1 and B2.

Component Impact

(Requires devs input)

Customer Impact

Web Chat.

If both the bot and user send activities to each other very rapidly, the out-of-order behavior can be observed.

Tracking Status

Dotnet SDK

• [ ] PR
• [ ] Merged

Javascript SDK

• [ ] PR
• [ ] Merged

Java SDK

• [ ] PR
• [ ] Merged

Python SDK

• [ ] PR
• [ ] Merged

Emulator

• [ ] PR
• [ ] Merged

Samples

• [ ] PR
• [ ] Merged

Docs

• [ ] PR
• [ ] Merged

Tools

• [ ] PR
• [ ] Merged

[dcr]

[EricDahlvang]

Won't this still be an issue if the bot code is scaled sideways, or processing messages asynchronously?

[compulim]

• Sideways: yes, but less likely than today, and also controllable
  • Given 2+ bots with two thread: U1 -> B1 -> B2 and U2 -> B3 -> B4.
  • There will still be race conditions between: U1 thread and U2 thread
  • U1 thread and U2 thread can still race against each other and U2 could appear before U1
  • But inside the thread, they won't, i.e. it must be U1 -> B1 -> B2 but never in any other orders
  • If the developer want U1 before U2, they should use distributed mechanism to control the behavior, which you cannot do it today
• Asynchronously: I assume you are talking about U1 -> B1/B2, which B1 and B2 are two asynchronous operations
  • The bot responses will be sent from the same box (otherwise, it's in the area of proactive messaging)
  • How B1 and B2 is presented to the user, can be controlled by the bot through in-proc concurrency control like semaphore or mutex
    • Today, it cannot be controlled at all