Hi all,
I have a flow which runs perfectly, but doesn’t finish, so the status is always on running.
Even when I quit the bot manually, the status stays on running.
The only thing that I could come up with was that I might have forgotten to exit chrome, outlook, excel or word in the flow. However, after triple checking, I don’t think I have…
Can you think of any other reason for this?
Thank you,
Michaela
Hi Michaela,
Does your flow run into any Exceptions? You can find out by checking the timestamp in the log file. You can find the log file by opening the Liberty RPA Settings app and clicking the “View logs” button.
Typically this is a sign that there’s still an application which needs to be closed off. It can either be the browser (Chrome), Outlook, or any other app which the bot is “attached” to.
You can wrap your flow in a sub-flow and assign a Exception node to another subflow which takes care of “cleaning up” the applications the bot used (ultimately killing the processes by name is an option).
Hope this helps!
Kind regards,
Koen
Hi Koen,
thank you for the quick response.
All the exceptions in the flow should be handled correctly as well as the cleaning up. But I will recheck this.
However, the flow ran perfectly fine, without exceptions that were not handled.
The log file says this:
2022-05-10 08:09:13,058 [INFO]: >>> # Save (Y4rQ)
from rpa.activities.office.excel import Excel
Excel.save(excel, )
2022-05-10 08:09:13,058 [INFO]: RPA (activity): Save
2022-05-10 08:09:13,214 [INFO]: >>> # Quit Excel (Iqsv)
from rpa.activities.office.excel import Excel
Excel.quit(excel, )
2022-05-10 08:09:13,214 [INFO]: RPA (activity): Quit Excel
2022-05-10 08:09:13,464 [ERROR]: Could not reach RPA Controller. Waiting 10 second(s) before retrying.
Traceback (most recent call last):
File “rpa\gui\apps.py”, line 323, in _runner_thread
File “rpa\gui\apps.py”, line 250, in run_flow
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xe4 in position 41499: invalid continuation byte
2022-05-10 08:09:37,246 [INFO]: Sent alive to RPA Controller.
So that seems to be a problem with reaching the controller?
Or is this the error when something is not closed?
Hi Michaela,
Could you please provide us with the output for:
import sys
print(sys.stdout.encoding)
You can run this in a Python code node or line by line in the console.
This should be utf-8, if not, that’s likely where the problem lies and your system locale might be configured to a different encoding format.
Kind regards,
Koen
Hi Koen,
the output I get is ‘None’.
However, this should also affect the other flows, no?
But these run fine and also complete.
In the flow I am using locale to change the output of datetime to german
locale.setlocale(locale.LC_ALL, "deu_deu")
which then gives as output
locale.getlocale()
("de_DE", "cp1252")
I tried setting this back to default which is
(None, None)
which worked, but the flow still couldn’t reach the controller then.
I narrowed it down quite a bit now and it seems that the problem appears as soon as I define some strings in german that contain ä and ö.
They are written correctly in the Word file, where I really need it like that, but then the problem appears in the end that I cannot connect back to the controller.
Is there a workaround that comes to your mind?
Thank you for your answer above, I never would have realized that it could be related to this otherwise 
Could it be that sending the log-file to the controller is the problem?
The character number seems to more or less work with when ä appears in the log file?
Hi Michaela,
I need to perform some further research on what the locale.setlocale() does, but the LC_ALL/locale objects impacts how Flow output sent to the Bot is encoded (the Bot expects UTF-8 encoding for any feedback from the Flow) and ultimately to the Liberty RPA Controller. Most likely you have a print() in there or a Print to Console activity which prints the ä character (which is most likely encoded in latin-1 or some other default for deu_deu/cp1252). I’d expect if you refrain from printing that to the log output, you should no longer get the error. Defining those variables should be fine, as long as you are not printing them in combination with changing the interpreter’s locale settings.
I would suggest to try removing the prints of those “ä” characters and try again.
Typically we would advise to refrain from changing locale settings of the interpreter as this might have unexpected results especially with other libraries which can make assumptions about locale (I assume you are using pandas etc.).
If you want datetime objects to be formatted in German format, you can also use the datetime .strftime() method (more info here datetime — Basic date and time types — Python 3.10.4 documentation). That way you won’t have to change the locale of the interpreter I assume.
Hope this helps!
Kind regards,
Koen
Hi Koen,
I actually checked only changing locale LC_ALL and that did not affect the communication to the controller, so I think this should be fine.
As for datetime.strftime() - the language the month is given in is defined by the locale, so this was my point when changing it
I am however not sure how to keep the 'ä’s and 'ö’s out of the log file. I am not printing the variables. In my understanding the log file contains the console output, right? So as soon as I assign a variable with ‘ä’ this will appear in the log file?
Thank you and all the best,
Michaela
Hi Michaela,
I understand your situation. To exclude the ä from the log files, one option would be to read that value from a file or an environment variable or from a credential in the Controller. That way the value itself will not be included in the logs. This would at least circumvent the issue you are facing right now.
I’ve taken this feedback to the drawing board and we will include a improvement for the next release (22.2) which allows you to hide the value of a Set Variable activity (might be a separate activity). In addition, we are looking at functionality we might be able to add to change the locale of dates.
Kind regards,
Koen
Hi Koen,
great, thank you for the quick responses and the work around! I will try to implement these 
.
Also, sorry for the very specific questions, but I really appreciate your reactiveness!