Result block don't get updated properly

[DivadNojnarg]

Our latest PR breaks the result block.

Steps to reproduce:

• Add a stack with dataset block.
• Add a new stack with result block.
• Add select block to first stack and select the first column.

Output: data are not updated in the second stack. This will likely affect the join block too.

[nbenn]

@DivadNojnarg

I have been playing around with this quite a bit and there is one thing that has me confused:

If you start up the app as

serve_workspace(
  stack1 = new_stack(
    new_dataset_block("BOD"),
    new_select_block()
  ),
  stack2 = new_stack(new_result_block("stack1"))
)

the app is "broken". If you start up as

serve_workspace(
  stack1 = new_stack(
    new_dataset_block("BOD"),
    new_select_block("Time")
  ),
  stack2 = new_stack(new_result_block("stack1"))
)

we're all good.

It seems like the validation failure in the first setting somehow "breaks the reactive chain" and this "breakage" is not cleared up after the issue is fixed.

In either case, I do not understand why evaluate_block() is executed in

blockr/R/server.R

Lines 225 to 232 in 061ac78

	reactive({
	req(is_valid$block)
	if (is.null(in_dat()) && !inherits(x, "transform_block")) {
	evaluate_block(blk())
	} else {
	evaluate_block(blk(), data = in_dat())
	}
	})

in the latter case, but not the former case. In both, blk() does not change.

Adding to the confusion: If you go ahead and change the data (in "stack1"), you again have an "invalid" state (in the select block) but this time nothing breaks and as soon as the issue is resolved all works fine.

[DivadNojnarg]

@nbenn I looked at it a bit more. Could you try from #435 hotfix2-result-field? There might still be some edge cases, but it seems to work from your examples.

For the long term, I will continue to work on #427 with the stack validation to hopefully get a more robust solution.

[DivadNojnarg]

Summary of findings with @nbenn:

• Putting a break point within the update block observer:

obs$update_blk <- observeEvent(c(r_values(), in_dat(), is_prev_valid()),
        {
          # 1. upd blk,
          if (inherits(blk(), "result_block")) browser()
          b <- update_blk(
            b = blk(),
            value = r_values(),
            is_srv = is_srv,
            input = input,
            data = in_dat()
          )
          blk(b)
          log_debug("Updating block ", class(x)[[1]])

          # 2. Update UI
          update_ui(b = blk(), is_srv = is_srv, session = session, l_init = l_init)
          log_debug("Updating UI of block ", class(x)[[1]])

          # Validating
          is_valid$block <- validate_block(blk())
          is_valid$message <- attr(is_valid$block, "msg")
          is_valid$fields <- attr(is_valid$block, "fields")
          log_debug("Validating block ", class(x)[[1]])
        },
        priority = 1000
      )

We found that in the first case (first stack is invalid), r_values() contains the data, whereas in the second case (all valid) r_values() contains a reactive expression. This looks strange as we update the stack with:

observeEvent(
        c(
          get_block_vals(vals$blocks),
          get_last_block_data(vals$blocks)()
        ),
        {
          vals$stack <- set_stack_blocks(
            vals$stack,
            get_block_vals(vals$blocks),
            get_last_block_data(vals$blocks)
          )
        }
      )

get_last_block_data(vals$blocks) being the reactive result expression. In both case, we enter this observer, which means something is overwriting the result in the first case (?)