ShinyQueue refresh interval vs producer emitting rate

[xwanner]

Hi,

I'm facing an issue with the IPC package, as I use it for emitting some signal from ExtendedTask + mirai processes to the main Shiny app, I realized that the refreshing rate of the queue (defined with queue$consumer$start(rate) ) could make skip some messages if the messages are emitted too fast.

Actually I found a workaround but I was surprised that the queue was not persistent until the message was read. Is it the normal behavior ?

Here is a minimal example of what I am talking about.

In this example, we emit a number every 100ms, but the consumer reads the queue only every 200ms. We can see in the console that it skips 1 on 2 values. If we change the consumer rate to less than 100ms, all values are output.

Thanks for your feedback, as this behaviour (keeping track of the queue) could be useful for logs or just to be sure we don't miss any communication.

By the way, the package is awesome and I use it all the time ! Thanks for all the work done !!

library(shiny)
library(ipc)
library(mirai)



ui <- fluidPage(
  actionButton("run", "Start Task"),
)

server <- function(input, output, session) {
  
  # IPC queue
  queue <- shinyQueue()
  queue$consumer$start(200) # change to less than 100 to get all values
  
  log_text <- reactiveVal("")
  
  # Append to log
  observeEvent(log_text(), print(log_text()))
  
  
  
  task <- ExtendedTask$new(function( queue){
    
    mirai({
      for (i in 1:10) {
        Sys.sleep(0.1)
        queue$producer$fireAssignReactive("log_text", i)
      }
    }, queue = queue)
    
  })
  
  # Trigger async task
  observeEvent(input$run, {
    
    
    task$invoke(queue)
    
  })
  
}

shinyApp(ui, server)

[ifellows]

I'm glad you've found the package useful!

I'd say that this is expected behavior. It's not that the queue isn't persistent. log_text gets assigned each value but you are overwriting it before Shiny has seen the original value. This is much the same as if you had another button with the following server code:

  observeEvent(input$another, {
    
    log_text("1")
    log_text("2")
    
  })

Here "1" will never be printed because it gets assigned "2" before the log_text observer gets executed.

As you noticed, there is a work around: Append new messages to the log, don't overwrite.

[xwanner]

Ok, thanks it's clear to me now.

I didn't realize that multiple change of a reactive value in a single event would trigger only one event in the end. I had think that the shiny behavior was to trigger as many events as changing values, but it's not.