sorry about the late reply, I didn’t get a notification for your update.
I asked about the testing in debug mode because we know that that type of testing can show as not closing the connection.
The terminal viewer window runs on the UI thread. Somehow, the debugger keeps the UI thread locked and the viewer cannot finish its exit procedure. The actual connection is terminated in the background but the viewer stays open.
So, testing in debug mode is not relevant for closing the connection. Use regular execution for testing.
The KillProcess activity cannot be used to terminate a DirectConnection terminal session. This type of terminal session executes inside the UiPath.Executor process, which executes the whole job. If you try to kill it, the whole job will crash.
Right now, to me, it looks like you are handling the closing of the connection properly. It’s only that the debugger execution created some confusion. There is not need to try to kill any process.
If you want to make sure, you can programmatically end the terminal connection by calling the Shutdown() method on the terminal connection object.
I also made a small test case that replicates the system exception scenario that you described. See the screenshot below.
The behavior that I’m seeing is that after the try/catch, during the execution of the delay, the terminal viewer is closed (connection is closed).
But if I uncheck the Close Connection option in the session, the connection will still be open. You can still try to recover from the exception and reuse it.
You also mentioned that
we noticed that when a system exception occurs inside a terminal session , the Output Connection arrives empty.
To avoid this behavior, try to have your initial terminal session make minimal operations, like in my test case, that only establishes the connection. The output connection is populated only on successful execution of the body of this session.
