what is progressr's error handling model?

[twest822]

Couldn't find this in the docs, previous discussions, or issues. Given code like

p = progressor(steps = n)
tryCatch({
    for(i in 1:n)
    {
      # perform task step
      p()
    }
  },
  error = function(e)
  {
    # do error handling
  })

what action, if any, should the error handler take notify p of the abort and that the progress bar can be disposed rather than getting calls to p() all the way to 100%?

I'm not seeing that progressr has an API for this so I'm wondering if perhaps the design is that callers should do

with_progress({ tryCatch({ ... }, { ... }) })

with progressr disposing when the with_progress block returns regardless of the number calls of p() which might have been missed due to an error occurring? Class progressor has only length and print methods so it doesn't appear possible or for callers to query it for the number of times to call p() to reach completion (not that completion particularly makes much sense an error condition).

Asking because I've got long running future_map()s calling numerical optimization methods that sometimes fail and occasionally future gets hung up when a worker errors and has to be reset. This not uncommonly yields a bunch of complaints from progressr about incomplete progressors.

[HenrikBengtsson]

Sorry for the late response. I think I understand what you're after, but not 100% sure:

If you're using with_progress({ ... }), there's nothing you need to do.

The with_progress() function takes care of "closing" the progress reporting on exit, regardless of how it exits. If it exits normally without errors, including when errors are already handled like in your example, it is closed, e.g.

with_progress({ 
  p <- progressor(10)
  tryCatch({
    for (kk in seq_along(p)) {
      Sys.sleep(0.1)
      if (kk == 3) stop("boom")
      p() 
    }
  }, error = function(e) {
    message("Caught an error")
  })
})
#> Caught an error 

If there's an non-handled error or user interrupt, it finishes the progress, but leaves the amount of progress visible, e.g.

library(progressr)
handlers("cli")
with_progress({ 
  p <- progressor(10)
  for (kk in seq_along(p)) {
    Sys.sleep(0.1)
    if (kk == 3) stop("boom")
    p() 
  }
})
#>   ■■■■■■■                           20% |  ETA:  1s
#>  Progress interrupted by simpleError condition: boom
#>  Error in withVisible(expr) : boom

Is this what you're after?

PS. What's missing in progressr right now is a way for you to signal that "I've already handled the error, here's the error, so please report on that on exit". Maybe something as simple as p(condition = e). I'll have to think about that and see if it can be added. I created #199 to track this feature addition.

Class progressor has only length and print methods so it doesn't appear possible or for callers to query it for the number of times to call p() to reach completion (not that completion particularly makes much sense an error condition).

Yes, by design it's impossible to query how far progress is. That can only be inferred by the progress handler, which collects all the progress updates. An analogue is where you receive letters in the mail from different parallel workers, where each worker reports back how many steps they made progress on. The workers don't know about the bigger picture, how many other parallel tasks there are, etc. They only know there on set of sub-tasks. It's only you as the orchestrator who can tally up the total progress made.