I'm on heroku and they cycle dynos every 24 hours and this results in losing all conversations (I assume).
Is there a way to use botkit's storage system to save open conversations and resume them when each team's bot is spun up? I'm currently using the postgresql storage driver for botkit.
The storage modules have nothing to do with persisting state, it is for storing attributes about a user or channel or team. Botkit doesn't currently have native support for restoring things in the manner you describe, but we're considering ways to provide that. We will of course review any PR's around this functionality suggested by the community.
@peterswimm has anyone tackled this issue yet? If not, I'd be interested in working on this problem. I'm losing important conversations after every deploy. I didn't see any improvements related to this in the changelogs.
@makstaks Sure! We will happily review any efforts made by PR's adding this functionality.
hey @makstaks, I'm working on an application using botkit and just realized that conversations were not persistent. We need to scale the app to multiple machines and I don't think this will be possible since botkits conversations are in memory. If you were to work on this that would be so cool!!! -- & I'd be happy to try to help. Do you have a sense of a timeline of when you'd be working on this? My other alternative is to re-write our app using Microsoft Bot Framework, but I'd rather keep using botkit if possible, would be incredible timing
It's impossible to work with Botkit and load balancers. I'm moving huge chatbots for the Microsoft Bot Framework. :(
Hello Botkit team.
I'd like to learn if there has been any progress in this regard. Are you planning to do it? or perhaps already discussed how to design this solution so developers can help modify/build it?
Thanks!!
Isn't there a channel object (like users and teams) in the storage for this?
@benbrown this is an important point, any plan to support conversation storage ?
@mhfowler I haven't begun the work on this yet, my workaround has just been informing the user someone bad happened with the conversation (_lame_). I've been focusing on other aspects of my bot that are higher priority at the moment. I won't be working on this problem for at least another month.
I never considered using Microsoft's Bot Framework because at the time I looked at it, I think it was still using Howdy Botkit. Looks like they've made significant improvements.
@makstaks what I ended up doing was not using botkit's conversation feature and instead adding a callbackPath string to my user object which determined which function to call when receiving an incoming message https://github.com/CallParty/CallParty/blob/master/backend/app/botkit_controller/listener.js#L7
and to determine the flow of conversation, in the response to a message, we set the user's next callbackPath like this https://github.com/CallParty/CallParty/blob/master/backend/app/conversations/signupConvo.js#L49
I came up with this pattern after playing around with Microsoft Bot Framework (this is essentially what they do). We chose to implement ourselves instead of use Bot Framework, because we didn't want to rely on one more intermediary service.
for our case we didn't need multi-threaded conversations, so this fairly simple approach worked well for us.
For me, I valued conversation persistence
@mhfowler amazing, thanks for sharing this, I'll give this a try this week.
How has this worked out? I absolutely need conversation persistence, but we use multi-thread conversations all the time. I may have to look into building this out to integrate with my GraphQL + Lambda setup.
We are also interested in developing a solution together. @peterswimm what are the plans? Using Bot Builder from Microsoft isnt the solution, because I would only need this one feature and not the whole Microsoft Bot Suite
@simonfranzen as mentioned lightly in the other thread, the best thing now is to craft a solution based on your needs using a storage connector, and user data logic using a middleware for whatever data you need to persist in your bot application. We hope to make this a native feature in Botkit 1.0,
Hi @peterswimm, when are you planning to release the version 1.0 with this feature? I am building a new chatbot and will plan accordingly
There is no firm ETA atm.
@peterswimm do you have some ETA now?
Nothing has changed since my last post, but we hope to announce something soon.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
@makstaks what I ended up doing was not using botkit's conversation feature and instead adding a callbackPath string to my user object which determined which function to call when receiving an incoming message https://github.com/CallParty/CallParty/blob/master/backend/app/botkit_controller/listener.js#L7
and to determine the flow of conversation, in the response to a message, we set the user's next callbackPath like this https://github.com/CallParty/CallParty/blob/master/backend/app/conversations/signupConvo.js#L49
I came up with this pattern after playing around with Microsoft Bot Framework (this is essentially what they do). We chose to implement ourselves instead of use Bot Framework, because we didn't want to rely on one more intermediary service.
for our case we didn't need multi-threaded conversations, so this fairly simple approach worked well for us.
For me, I valued conversation persistence