delete models does not stop backend flask_ml job

[nb950]

refer fix #330 #329 #228 the UI can delete running model task. this works ok for the UI feature, however backend flask_ml job that was started continues to run , in other words end-2-end delete should be handled .
There needs to be a feedback that model task and cleanup was done on the backend and then UI shows delete success
or "request to cancel issued" to backend message in UI
or "document used has to manually stop and cleanup" backend to match the frontend "delete"

[atharvakale343]

Currently, this is how RBox Desktop works:
when user starts a new job, a POST request is sent to FlaskML backend in a concurrent asynchronous requestFlaskML does all the ML work, POST request is still pendingEventually FlaskML backend finishes, and POST response is sent back to frontendFrontend declares job is successful
Also, currently, when user starts “cancels” a job in the frontend, it simply updates the job status to cancelled, and the POST request continues to be outstanding (no notification is sent to FlaskML backend that the job was cancelled). This becomes even worse when the model is deleted when a job is running.

With the current version of the API contract between frontend application and FlaskML, there is no way to indicate events such as “job cancellation” or “frontend application was closed by user”. As such, it is on FlaskML backend server to maintain data integrity.

All these issues can be easily solved/and should be solved when you make the big migration to single server backend. In doing so, you should move away from the simple POST request-response model, to a START-POLL-FINISH model. Although this adds complexity, it gives you more flexibility in conveying events such as cancellation.

Moreover, as you may know, it is difficult to do “transactions” across services. So it would still be the responsibility of each service (frontend application, backend server etc.) to maintain data integrity in the face of failures.

I don’t think it’s worth fixing this right away in the RescueBox Desktop repo, since if you are imagining big changes to the codebase, it will have to be done anyway (and then this change would become throwaway code)