Botpress: Graceful shutdown / improved resilience

[jbourassa]

It is my understanding that messages in botpress are queued in-memory, which means that some messages can be dropped if the bot crashes or shutdown. I'm assuming that changing that design decision is not going to be a walk in the park, but I'm wondering if we could implement graceful shutdown?

I'm thinking that botpress could respond to SIGINT and do the following, in that order:

• Stop accepting incoming HTTP request
• Finish sending all messages in all conversations

Additionally, botpress could expose an extra event / config that would allow third party code to also gracefully shutdown.

Thoughts?

[slvnperron]

Botpress community is queuing in memory.
Botpress Enterprise – which hopefully will see the day in this project – will queue messages in Redis.

This version of the Enterprise edition is not quite ready (we're working on a major release, but will essentially enable a distributed architecture.

Gracefull shutdowns are only a plaster to the underlying problem. When servers crash they rarely allow a grace period.

[ricardovsilva]

@slvnperron what is your opinion about just abstract incoming and outcoming process? I mean, botpress can still work, by default, in the way that it's work today. But would be awesome if botpress empower developers to improve incoming and outcoming process (such as adding messages to a queue menager)

[slvnperron]

@ricardovsilva Good point. Let me think about it and come back to you.

[slvnperron]

Just an update on this. This has been implemented and will be released in January as part of the Botpress X. Botpress now queues messages and in Botpress Pro messages are queued to Redis with persistence. Both in-memory and redis queues have retry policies and prioritization.

[ricardovsilva]

@slvnperron if I correctly understood, capability to external queue message only currently exists and will only exists at enterprise version. Is that correct?
If I create a PR that adds that capability to open source version, will that be appreciated? Because I'm seeing a conflict of interests there.

[slvnperron]

@ricardovsilva What could possibly be a conflict of interest in us having full time people working hard to build a free product for the community and making it open-source? I don't think there's anything wrong with trying to make a business, that's called the open-core model.

By the way you're free to swap things as you wish on your side, but we obviously won't merge pro features in the community version for many reasons, including sustainability of the business model but more importantly reducing the friction (having as less dependencies and setup in the community version as possible).

I'm sure you understand that.

[slvnperron]

@ricardovsilva Queuing will exist on the community version too, it just won't happen in Redis.

[ricardovsilva]

@slvnperron I know that you have a business, that is Botpress Enterprise, and there's no problem at all for me in that model.
My point there is that I want to know how much free will Botpress Community be from Botpress Enterprise.
There's no problem at all that you and your team develop things that you will just release at enterprise version.
My doubts there, and maybe it's doubts of others developers too, is if some PR could be denied simple because it have some feature that you want to keep exclusive to Enterprise edition.
I don't know if I was clear. Also I believe that BP community have to be more decoupled as possible from external technologies, but it still have to add capability to devs to use their preferred technology stack attached to no.
If you see my other comments, I'm not asking to bp team to open specific integration with redis, what I'm asking for is to bp team empower community with capability to add redid integration or any other integration that they want.

[slvnperron]

@ricardovsilva I totally agree with that and I understand your point. The pro/enterprise versions are targeted at agencies and enterprises, our view is that we should never refuse or limit in any way features that make sense for 99% of the people and we should always make it easy for people to add/hook/extend the community version if they wish to.

The pro version currently provides:

• Multi-users access, with ACL
• Enhanced security
• Scalability to multiple nodes
• White Label interface

These are things will almost never make sense (and overcomplicate) for 99% of the people who just want to get started building bots or building bots for themselves.

That being said, every major open-core software has had diverging opinion from the community in the past and we expect some people to also argue in our case. That's fine – people are free to chose Botkit or Microsoft Bot Framework (which both have similar business plans, i.e. capturing your data in a SaaS offering) if they don't appreciate what we are doing here.

[mrbarletta]

I am in favor of limiting PRs that could harm the botpress business model and its sustainability.

I also think that with proper hooks/extensions/ plugins support, initiatives as the one from @ricardovsilva will not be in vain as it could exist as a community plugin and the maintenance burden/complexity will be out of scope for the botpress team.

We have an agency and we are initiating our journey with botpress (we used recast.ai before) we would love to see an enterprise version (with an affordable pricing ) and a healthy community (in case enterprise is out of budget and we can manage to implement @ricardovsilva plugin :+1: :smile: ).

Hope the botpress team finds the right balance in the force.

[slvnperron]

Thanks Matias, would you mind emailing me at [email protected], would love to send you an overview you the upcoming version and would also love to pick your brain :)

@mrbarletta

[epaminond]

There's a lot of offtop in this issue, but:

1. In-memory queuing was implemented and is available in Botpress X
2. Subscribing to SIGINT events works and you can extend current functionality if needed.

So closing this issue unless someone has objections. :slightly_smiling_face: