It is missing information of millisecond precision for log dates in Orchestrator. For now rows are not being sorted in right order, I don’t think it is something hard to implement; adding millisecond precision to Orchestrator log list dates.
How many logs per second are you sending to Orchestrator?
Orchestration are effectively stored as DateTimeOffset format (see bellow screenshot) which is going even above the level of precision you described.
However they are not exposed as such to the directly end user on the list and this an interesting idea to do so
However, I also experienced, notably from the studio, mixed order of the execution logs as well.
Orchestrator is maybe not the place where this could be fix but maybe from the activity side on the studio.
Would you have an example of Orchestrator log details disordered showing a similar screenshot with the DateTimeOffset value?
@badita there are 2-5 logs per second.
Yes @Florent_Salendres you’re right, logs are stored with millisecond precision but I think the list in orchestrator sorts them according to their second value by dismissing millisecond. Unfortunately I can’t share any screenshot but if you create a test job that writes 2-5 jobs per second you’ll see that the sequence is mixing for the same second, even it contains millisecond precision in log details.
Count me in on this one.
We have duplicate logs. (see Bug in Orchestrator Logging?)
It is easier to see these are real duplicates when the time column displays up to the millisecond.
This has been an issue for my organization as well. Our management decided to turn on verbose logging and sometimes reading the logs in Orchestrator can be difficult due to the incorrect order of activities in the list view.
This needs to be a thing.
Currently, if I were to trust my logs, I’d say the robots are sometimes executing sequencial steps out of order.
Alternatively, I can’t trust my logs.
Neither is acceptable. Please add aditional precision…
Any update on this issue from UiPath?
It’s been almost five years. Are there any plans to fix this issue?
They’re busy with more important things
This information is available to the end user in the Orchestrator, its just not displayed natively.
In my experience attaching listeners to the logging I have found that they can be added to the orchestrator inconsistently, I believe this is because the Orchestrator is the one that actually adds this time stamp, not the robot executor and the log messages are sent, via API, asyncronously and if you are firing off several log messages per second then sometimes they don’t all complete at the same speed resulting in a different order of some log messages.
I think a more interesting question is what meaningful information are you logging if you are doing it so rapidly that several queue up per second resulting in this behaviour?
On another note, it has been on my todo list to make a ‘Logging Scope’ where you can capture all log messages for any activities inside it, this would bypass the Orchestrator so perhaps could give more ‘accurate’ log messages, but again I dont think thats really a great use for it, my idea was more to make it easier to grab logs for one part of your process, say a single transaction, without needing to mess around with API calls.