Open ranrubin opened 4 years ago
Hi @ranrubin
The original bug (#49) is actually a bug in Trains (even though the manifestation is in the trains-server) . The bug is, Trains will try to create links that the file storage might not support (basically there is a filename length limit, e.g. s3 object storage has its own limits, and shared filesystem as well). A fix will be deployed in the next RC (due in a few days).
But regardless of the original bug, are you suggesting a per Task section capturing the stderr, for easier readability? Or, are you saying it will be nice to get the trains-server log in the UI?
Hi @bmartinn, thanks for commenting. I'm not familiar enough with trains to define what I mean as well as you defined the situation in your comment. Putting it simply, I would say that - as a user of the UI, when an error occurs, I want to see the exact reason for the failure rather than a generic "500" message.
Feature request
When running an experiment code, the UI displayed an error from the server (500), but with no details regarding the cause. After exploring the logs I found out that the fileserver crashed because the file name was too long.
I would love a way for the UI to clearly display all kinds of errors encountered by the experiment (including, but not limited to, file names being too long...)
The solution I would like
I would rather get a message in the UI saying that the file name is too big, rather than have to look for the issue in the logs
Additional context
Logs from
/opt/trains/logs/fileserver.log