Removing the last reactive KI from a Knowledge Base through the REST API should prevent the Knowledge Base suspension.

[Sophietje]

In GitLab by @barry.nouwt.tno.nl on Oct 3, 2023, 13:35

When you register a single reactive KI (so REACT or ANSWER) through the REST API it double checks if you actually listen to incoming requests. If you do not for a particular amount of time, your KB will be suspended (because otherwise you block data exchange between other KBs) and deleted. However, if you, do not listen to incoming request, but remove the final reactive before the suspension time is reached, your KB should not be suspended, but it does.

[Sophietje]

In GitLab by @cdemulde.openmotics.com on Oct 4, 2023, 15:21

I just bumped into this issue as well, in the case where I had two KIs registered on the same KB, a React and a Post one.
In my case I call both sequentially, leading to the following: a bug in my Post call made it hang, causing my React call to stop polling for a while (about a minute). The knowledge base was therefore removed by the KE, and when the Post call finally returns with a timeout and the polling of my React call can start again, it does not work, because the related KB was removed.
More generally, it indeed seems like a bad idea to remove a KB that has multiple KIs linked to it because one of those KIs fails to poll for a while.

[Sophietje]

In GitLab by @barry.nouwt.tno.nl on Oct 5, 2023, 07:55

Hey @cdemulde.openmotics.com, thanks for the explanation.

Yes, it is certainly not ideal that we have this suspension mechanism in place, but unfortunately, without it, abandoned KBs with reactive KIs blocked data exchange all together. We would like to implement a timeout mechanism, but we currently do not have the resources to do so.

In the meantime, I would recommend decoupling the reactive polling mechanism from the KI handling mechanism, so that the polling is always immediately restarted after receiving a request to handle a KI. The ordering in which you respond to handle requests should not matter if you are using the correct handleRequestId. So, you could put the handle requests that you receive through the long polling mechanism in a queue immediately and use a separate thread(pool) to deal with those and send the responses when they are done (i.e. the timeout occurs in your example).

Hope this helps!

Best regards,

Barry

[Sophietje]

In GitLab by @cdemulde.openmotics.com on Oct 5, 2023, 08:47

Hi @barry.nouwt.tno.nl ,

Thanks for getting back and for the suggestion, I've added it to our to do's!

Best regards,
Chaïm