This may also be a good time to think about whether we want to keep using the existing names too (live.log / live_backing.log). My preference would still be that we have a single log artifact, public/logs/task.log - and that is the livelog artifact during task execution, and the backing log after task completion. It still feels very awkward to have two different log artifacts for the same log, especially as public/live/live.log is not live after task completion, but points to the backing log. A task consumer can always see if a task is running or not from its state, so we don't need separate artifacts in for the consumer to know whether the task is complete or not. It also makes it awkward in the UI, and just more complicated for the user than it needs to be.
Bug 1598689 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This may also be a good time to think about whether we want to keep using the existing names too (live.log / live_backing.log). My preference would still be that we have a single log artifact, public/logs/task.log - and that is the livelog artifact during task execution, and the backing log after task completion. It still feels very awkward to have two different log artifacts for the same log, especially as public/live/live.log is not live after task completion, but points to the backing log. A task consumer can always see if a task is running or not from its state, so we don't need separate artifacts in for the consumer to know whether the task is complete or not. It also makes it awkward in the UI, and just more complicated for the user than it needs to be. A single log file called "task.log" just makes more sense. The downside of course is that it is a breaking change.