Task files are deleted when monitor websocket is closed

[Astor-Bizard]

Hello,

This problem does not occur with standard VPL plugin. However, I believe this is a design problem that leads to some errors when other systems try to communicate with the jail server.

Steps to reproduce:

• Request an evaluation
• Open a bidirectional websocket communication with the jail server on monitor URL.
• Wait for "retrieve" message
• Properly close the websocket connection (as it was only meant to monitor, we don't need it anymore)
• [optional] Sleep for ~1 second, or maybe wait for the server response to the close signal
• Retrieve the result of the evaluation

Expected result: The last step should yield the result of the evaluation

Actual result: An error is raised:

Internal Server Error

Internal Server Error

Ticket invalid format

This error disappears if the step "properly close the websocket connection" is done last. Realistically, the close signal sent to the jail server makes it clean the task. Though not critical, this behaviour is not what it should be: closing the monitor websocket should not erase the evaluation result.

[Astor-Bizard]

Afterthought, I understand that stopping execution and cleaning the task upon websocket close is a way to respond to the VPL browser tab being closed, for example. In that case and if we want to keep this behaviour, it would at least be nice to have this documented somewhere :)

Best regards, Astor

[jcrodriguez-dis]

Dear @Astor-Bizard,

Thank you for your detailed bug report.

You've identified an issue where the monitor prematurely cleans up tasks when the websocket connection from the client is closed before the evaluation result retrieval is complete. This occurs because our code incorrectly stops monitoring and cleans the task if the websocket is closed, even though the task may still be in the retrieval phase.

We have address this problem (ed72898), now if the websocket is closed while the task is still in the "retrieve" state, the monitor will continue to wait until the retrieval process concludes or until the JAIL_HARVEST_TIMEOUT (set at 20 seconds) is reached.

While this fix should address the issue, I am open to exploring other strategies to manage potential endless waits more efficiently.

Again, thank you for bringing this to our attention.

Best regards, Juan Carlos