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.
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?
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.