Bot context TTL

Is there any issue with TTL? bot-context TTL did not work a few times (intermittently)".
I would like o add the we are using BotKit.

@sadhvi.chandra

First let us explain you How TTL works :

  • If you add a key value pair without TTL (as TTL is optional) under BotContext, it is perpetual
  • If you add a key value pair with TTL under BotContext, system respects the existing TTL

Example:

BotContext.put("key1", "val1", 48*60); // if the value set at 2020-04-01:00:00:00Z, the exipreAt will be 2020-04-03:00:00:00Z 
BotContext.put("key1", "val2");// if the value set at 2020-04-02:00:00:00Z, the exipreAt will still be 2020-04-03:00:00:00Z.
//This will try to make use of the exising TTL value.
  • If you try adding the same key with different/same value without mentioning any TTL, OLD TTL is respected and kept.
  • If you try adding the same key with different/same value without mentioning any TTL, AND TTL had expired by now, a new perpetual TTL updated against this key.
  • If you try adding the same key with different/same value with NEW TTL, new TTL is updated against this key (over-riding old TTL).

Also, let us add a little about BotKit behaviour

  • Every message/event that is sent to BotKit carries the complete session data.

  • BotKit can optionally modify the session data as needed, which includes context variables and TTL.

  • When an event/message is sent back to the platform from BotKit, the platform will update the session data and then do the message processing. The session gets updated always as the platform doesn’t know whether it has been changed at BotKit or not.

  • The session data sent back to the platform from BotKit will never carry the previously set TTL info. However, it can be overridden by BotKit by setting an explicit TTL . Please read the above rules explained for TTL, they also apply for BotKit.

  • Right now in bot kit, one cannot see the TTL info (expiry time or time to go for expiry). It is maintained only in DB.

With the above in mind, now consider a race condition:

  • When the context variable TTL is just about to expire, if there is a message from user, the same will be sent to BotKit along with session data including the “context variable” in BotContext.
  • While the message/event is being processed by the BotKit, the “context variable” in the BotContext gets expired .
  • Once the processing is done, the BotKit will notify the platform about the event/message. This request could carry the same old session containing expired data. And this gets updated in BotContext, without any TTL set to it (perpetual TTL).So, unless TTL is explicitly set again, it is perpetual.

Resolution:

  • Platform team will check for possible solutions without impacting any of the existing functionalities. But this could be really tricky and needs to be well thought through before providing any resolution.

Workaround:

  • Even if volume is less, concurrency could cause this. Even 2 concurrent messages can cause this.
  • And the problem is very specific to “BotContext“ and “EnterpriseContext” objects, which are shared across the users. The other ones like “BotUserSession“ should not have any problem, and TTL can be used as those are user-specific objects.
  • If BotKit is enabled, we would recommend not using TTL specifically in BotContext and EnterpriseContext objects until a resolution is provided by the platform. However, TTL can be used everywhere else(UserSession, BotUserSession).
  • In case you want of BotContext/ Enterprise context, please try to check the value of the variable rather than existence. In case the value (say the last updated time-stamp) is greater than some defined, hours you may refresh the token.

Hope this explanation helps.