Nested progress steps

[gadenbuie]

cli_progress_step() is an excellent solution for easy-to-use progress updates, so first thank you!

Do you have any recommendations about how to handle nested progress steps? I find that the progress steps work well when called linearly, but when nested the outer steps don't always perform as expected. On CI logs (like GHA) the outer steps are repeated with every progress bar update, and interactively sometimes the outer step isn't displayed.

library(cli)

outer <- function(batches = 1:2) {
  for (batch in batches) {
    cli_progress_step("Batch {batch}")
    Sys.sleep(0.25)
    inner(batch)
  }
}

inner <- function(batch) {
  cli_progress_step("Batch {batch} step 1")
  Sys.sleep(runif(1))
  cli_progress_step("Batch {batch} step 2")
  Sys.sleep(runif(1))
}

When called locally, I see something like this. Notice the missing Batch 1 updates.

outer(1:2)
#> ✔ Batch 1 step 1 [404ms]
#> ✔ Batch 1 step 2 [1s]
#> ✔ Batch 2 [1.8s]
#> ✔ Batch 2 step 1 [203ms]
#> ✔ Batch 2 step 2 [675ms]
#> ✔ Batch 2 [1.2s]

On CI, I see something like this:

outer(1:2)
#> ℹ Batch 1
#> ℹ Batch 1 step 1
#> ✔ Batch 1 step 1 [244ms]
#> 
#> ℹ Batch 1
#> ℹ Batch 1 step 2
#> ✔ Batch 1 step 2 [975ms]
#> 
#> ℹ Batch 1
#> ✔ Batch 2 [1.5s]
#> 
#> ℹ Batch 2
#> ℹ Batch 2 step 1
#> ✔ Batch 2 step 1 [946ms]
#> 
#> ℹ Batch 2
#> ℹ Batch 2 step 2
#> ✔ Batch 2 step 2 [27ms]
#> 
#> ℹ Batch 2
#> ✔ Batch 2 [1.3s]

I'd really like to achieve something closer to this:

outer(1:2)
#> ℹ Batch 1
#> ℹ Batch 1 step 1
#> ✔ Batch 1 step 1 [244ms]
#> ℹ Batch 1 step 2
#> ✔ Batch 1 step 2 [975ms]
#> ✔ Batch 2 [1.5s]
#> ℹ Batch 2
#> ℹ Batch 2 step 1
#> ✔ Batch 2 step 1 [946ms]
#> ℹ Batch 2 step 2
#> ✔ Batch 2 step 2 [27ms]
#> ✔ Batch 2 [1.3s]

[gaborcsardi]

I think the interactive output is conceptually correct apart from a bug when Batch 1 is finished, it should print Batch 1 instead of Batch 2 These are all the messages:

❯ withCallingHandlers(outer(1:2), cliMessage = function(x) cat("\n"))

ℹ Batch 1
ℹ Batch 1 step 1
✔ Batch 1 step 1 [323ms]


ℹ Batch 1
ℹ Batch 1 step 2
✔ Batch 1 step 2 [415ms]


ℹ Batch 1
✔ Batch 2 [1s]


ℹ Batch 2
ℹ Batch 2 step 1
✔ Batch 2 step 1 [759ms]


ℹ Batch 2
ℹ Batch 2 step 2
✔ Batch 2 step 2 [258ms]


ℹ Batch 2
✔ Batch 2 [1.3s]

The non-interactive output has the same bug.

As for the extra lines in the non-interactive output, these appear to let you know that the previous outer step is still running. E.g. when Batch 1 step 1 finishes, cli prints ℹ Batch 1 to let you know that Batch 1 is still running. Of course you immediately start ℹ Batch 1 step 2 so this is redundant in your case. But in general there is no way to know that, especially if the progress bars are coming from code written by different people.

Maybe we could have a way to tell the progress bar not to remind you that it is still running when a nested progress bar finishes.

[gadenbuie]

As for the extra lines in the non-interactive output, these appear to let you know that the previous outer step is still running. ... Maybe we could have a way to tell the progress bar not to remind you that it is still running when a nested progress bar finishes.

I'd be very happy with a way to suppress the nested progress bar reminder messages. I totally understand the design decision and it makes sense to me in general, but in practice I'm finding that it makes my logs much harder to read.

[gaborcsardi]

OK, this is not actually a bug per se. What happens is that batch 1 finishes when batch 2 starts and at that time batch is already 2, so the wrong number is printed.

That is unfortunate, but we can't make the message evaluate eagerly (when the step is created), because that's a breaking change, and sometimes you do want to evaluate it lazily, when the batch ends.

One workaround is to create a closure, so batch is not updated during the iteration:

outer <- function(batches = 1:2) {
  lapply(batches, function(batch) {
    cli_progress_step("Batch {batch}")
    Sys.sleep(0.25)
    inner(batch)
  })
}

The for loop is often more natural, though. Another workaround is to evaluate the message eagerly manually, i.e. something like

outer <- function(batches = 1:2) {
  for (batch in batches) {
    cli_progress_step(glue::glue("Batch {batch}"))
    Sys.sleep(0.25)
    inner(batch)
  }
}

But yeah, it is not very intuitive.

[gaborcsardi]

We should probably also document this pattern.