Block status independent of demand

[nbenn]

Problem

A block out of the eval set reads dormant whatever its last check found, so a consumer cannot tell a parked block that is current from one that failed, cannot run, was edited since or never ran (BristolMyersSquibb/blockr.core#362). Its result() is NULL although core holds the last result (BristolMyersSquibb/blockr.core#363). The reason a block cannot run is written by the render observer, so a block checked off screen by an evaluate request reads dormant with no conditions at all, and one fixed off screen keeps its old reason. The assistant's commit review read a parked block that failed as clean (BristolMyersSquibb/blockr.assistant#165), and holds sustain claims to see anything at all (BristolMyersSquibb/blockr.assistant#164).

Once solved, status, result, conditions and the reason a block cannot run read the same whether or not the block is in the eval set, and being needed only decides whether reading them runs a fresh check. A consumer that requests evaluate for whatever reads stale or unevaluated, and waits until nothing does, can read everything else as current.

Proposal

• Each check of a needed block records what it read (expression, state, eval trigger, which block feeds each input, what each of those held) and what it found, including that the block cannot run.
• The status is the last check's outcome while nothing it read has changed (ready, failed, waiting, unset), stale once something has, and unevaluated without a check. An upstream that is stale or unevaluated counts as changed, so staleness reaches the whole downstream cone. The dormant status goes, since it reported that a block is not being computed in place of what it would find.
• A parked block's result() returns the held result.
• The check records the reason a block cannot run, not the render observer, so the reason exists for a block checked off screen and clears once the block runs.
• A board block that is not built yet reads unevaluated rather than having no status, so a consumer waiting on stale and unevaluated does not skip it.

Work

• Record every check with its outcome and reason, and report the held outcome, stale or unevaluated for parked and unbuilt blocks, in blockr.core (An edited or never-run block that is off screen reads dormant, not stale blockr.core#362)
• Return a parked block's held result from result() in blockr.core (A block that is off screen returns NULL from result(), even after it has run blockr.core#363)
• Draw badges from the held outcome and drop the keep-last-badge case for dormant in blockr.dock (Draw status badges from a parked block's held outcome instead of keeping the last one blockr.dock#485)
• Read held outcomes for parked blocks and drop the sustain hold from the commit review in blockr.assistant (A commit reads back clean for a block that never ran, and the model reports it as done blockr.assistant#165)

Notes for implementers

BristolMyersSquibb/blockr.core#364 implements the check record (last_check, record_check(), dormant_status() in R/block-server.R), the comparison against the block's own expression, state and eval trigger, its wiring and each upstream's held result, and tests for own edits, rewiring, a changed upstream that is parked again, and expressions built from input data. Rework it rather than start over: report the recorded outcome instead of dormant, move the reason into the check, and have res() return last_check$result when the block is not needed.

A needed block's status has to read its result, which is what records a check for a block that cannot run (block_eval_status()). Keep state_ready() ahead of data_valid() in res()'s guard, so validation never runs on unset user inputs.

An expression built from input data cannot be rebuilt while its block is parked, as its inputs req() out: blockr.dm's dm_select and crossfilter blocks, and blockr.ggplot with fill or colour and blockr.theme installed. Compare such a block's state instead, so parking does not read as an edit.

The reason is written today by explain_block_status() from output_render_observer(), which render_gate_observer() suspends off screen. Measured on the #364 branch: a waiting or unset block checked by evaluate reads dormant with no conditions, and a block fixed off screen keeps its old "waiting" note although it ran.

A block's status reactive is installed at construction (construct_block()), and replacing a slot is what wakes a downstream reading it, so an unevaluated placeholder for an unbuilt block has to be replaced the same way.

Nothing else in core changes meaning. The input_ready() check compares against ready, and a needed block's upstreams are always needed, so a parked upstream reading its held ready changes nothing there. Evaluation requests wait on no status, unevaluated and stale (block_deferred()), so a request for a current parked block is spent at once.

Readers downstream: block_status_badge() in blockr.dock maps dormant to NA, meaning keep the last badge, and blockr.dag draws through it. In blockr.assistant, eval_status_notes() and eval_deferred() list the statuses, and BristolMyersSquibb/blockr.assistant#164 holds sustain claims for the review.

Leave room for a running outcome once evaluation can be asynchronous (BristolMyersSquibb/blockr.core#82). The interface spec, #489, changes when output_render_observer() runs, so land this one first.