Terminal Activities - Close Connection does not work

Hello,
I’d like to point out an issue that seems to be happening for a while already and no one has a solution to. At least, that’s what I gathered from these posts I found on the forum:

I want to close the terminal whenever I get a System Exception, so that UiPath can open a new one. What is happening instead, is that it’s not closing it and just opens a new one, so if I run 1000 cases where 50 of them have system exceptions, UiPath will open 49 more terminals on top of the original one…this is obviously not good…

The first idea was to put a terminal session on the “Kill All Processes” workflow, where this terminal session would only have a log inside and also have the “Close Connection” checked with the “Output Connection” empty, but this does nothing.

We’ve also tried using the “Kill Process” activity where we kill the terminal process, but doing this would then pop open this error message from studio itself:


(Translates to: Task ended with unexpected exit code: 0xFFFFFFFF

Then we tried to kill the sub-task instead, but this did nothing. Nothing would happen after going through the kill activity and the terminal would stay open.

Is there anyone that had this issue and managed a fix? Or someone that did not have this issue at all and can share what they are doing?

Thank you for your time!

Hi @J0Santos,

Can you provide the following details:

  1. The terminal provider used in the terminal session activity (ie: Direct Connection, EHLLAPI, etc)
  2. Are you seeing the above behavior in running in debug mode and regular execution?

I want to assure you that the behavior of closing the terminal session is tested with each new release since at least v2.5.0.

Hi @bogdan.gaspar,

We’re using Direct Connection for Terminal Sessions with the following connection string:

{'AttachExisting':true, 'ConnectionProtocol':'ProtocolX', 'ConnectionType':1, 
 'EhllSession':'SessionX', 'Host':'MyHost', 'Port':'MyPort', 'ShowTerminal':true}

This connection string is passed as an argument (in_OutputConnection_arg) to multiple Terminal Sessions using the “Existing Connection” property.

The Issue

Initially, the session didn’t work in Debug Mode, but after running it in “Run” mode once, it started working in Debug as well, which was odd. However, we noticed that when a system exception occurs inside a terminal session, the Output Connection arrives empty.

As a result, when we attempt to close the terminal connection using KillAllProcesses and the argument in_OutputConnection_arg, it fails because the connection value is missing.

Our Workaround

To ensure the connection can still be closed:

  • We save the Output Connection of the original terminal session into two arguments:
    1. One argument that passes through all workflows.
    2. Another that is used specifically in KillAllProcesses.

This way, even if an exception occurs mid-execution, we can still close the terminal. When a new session opens (after the exception), we overwrite the two arguments with the new connection value.

Question

This workaround feels a bit “scuffy” (inelegant). Do you have any suggestions for a better way to handle terminal session closures after a system exception occurs?

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.

I made another test case:
A Terminal session using direct connection and output connection variable (close connection not set), that has an uncaught exception is thrown in its body.

Indeed, the connection is not closed in this case. I made a bug report on this.

The workaround would be to use the approach I mentioned in the previous post: have your initial terminal session have no operations in it. Just establish the connection.

@bogdan.gaspar Thank you for taking the time to help us with this issue.

The main challenge we’re facing is the need to maintain a single terminal connection across multiple activities spread across several workflows. These workflows are connected through invoke activities, all using the same connection string as an in_argument.

The issue arises when a System Exception occurs. When this happens, the transaction moves to the KillAllProcesses workflow, but the connection string arrives empty. I believe this behavior is tied to a broader issue I’ve encountered in UiPath: if there’s an out_argument in a workflow and a System Exception occurs, the argument value is cleared—even if it was populated before the exception.

Side Note on the Argument Bug:
A workaround I’ve found for this issue is to use a dictionary of arguments instead of single values. For example, if you’re working with strings, create a Dictionary<String, String> and store the argument value inside the dictionary. This way, even after a System Exception, the value isn’t cleared.

Returning to the Terminal Issue:
To ensure the connection is closed every time, we’ve implemented a workaround:

  1. We use a single connection string for the entire transaction.
  2. To set up the connection, we create a dedicated empty terminal session at the start, which only handles the connection initialization - just like you suggest.
  3. We assign the connection string to two argument variables:
  • One variable travels through all the workflows, keeping them connected.
  • The other variable is reserved exclusively for the KillAllProcesses workflow.

Even if a System Exception occurs and clears the argument travelling through the workflows, the connection is still closed because the second argument (used only in KillAllProcesses) remains unaffected.

I understand this might still sound a bit convoluted, but it has worked reliably for us to handle exceptions and maintain proper connection closure.

I can’t share any images right now since I’m currently on vacation, but I passed your messages to my team. Maybe they can figure out a better way to handle this issue with your suggestions and if they do, I’ll let you know once I’m back.

OK. I understand now.

Your solution should work. Both variables are referencing the same object.

Another possible approach to work around the argument/exception issue is to try setting up the variable holding the terminal connection as a global variable.
This way you wouldn’t need to pass it around the workflows at all and the KillAllProcesses workflow would have a proper terminal connection to close.

1 Like