Updating of interface tags does not guarantee write to DB

[Ktmi]

Updating the tags of an interface generates an event, which is then later processed by topology to write the tag data to the DB. However, it is possible that before this event is processed kytos can crash or shutdown, or some other event can occur which prevents the write to the DB. This can lead to scenarios where another NApp reserves a tag, writes to the DB that it reserved a given tag, then kytos closes before the fact that the tag is in use is registered by topology.

[viniarck]

The the threadpool executors currently gracefully shutdown when the controller is stopped. So, for sigterm and sigint, it's expected to handle well. For sigkill, there's no guarantee in the application, incorrect state or corruption can happen if an admin doesn't manage it correctly.

We can consider in a next future opportunity to perform upsert_interface_details in the core, and then only allow the method to succeed if the DB write succeeded as you pointed out. Let's consider this low priority for now since the likelyhood of that one to blow up is low, and events out of order are already being handled.

In the meantime what can be done to also make it less prone to starvation in the app default pool would be to set that topology handler to use the db pool as it should've been from the start when it was introduced.

Good finding.