Add run_requested_timestamp
state to delete the run_multiple_cells
action
#2542
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an internal change to the way executions are triggered! Rather than the frontend requesting cell execution, cells have a timestamp in their state "when the user wanted the cell to be executed", which can be compared to "when we last executed the cell". This means that execution will now also be handled by our super cool state system, instead of a separate API call.
This PR should not change any behaviour, but it will help with future features, including #220 #1694
More detail:
Right now the frontend makes a request to the backend (
run_multiple_cells
) to run cells. So when you Shift+enter, we currently do this:cell_input[cell_id].code
in the frontend state, and computes patches from that change.run_multiple_cells
request to backendAfter this PR, the
cell_input
struct will have one new field:run_requested_timestamp
. And thecell_result
already has a fieldcell_result.output.last_run_timestamp
. So now, we can say:run_requested_timestamp > last_run_timestamp
. So the frontend doesn't need to explicitly request a run anymore.last_run_timestamp = run_requested_timestamp
.run_requested_timestamp > last_run_timestamp && !running
. So we can remove thequeued
field from our state and make it a computed field.So after this PR, the process is:
cell_input[cell_id].code
andcell_input[cell_id].run_requested_timestamp = Date.now() / 1000
in the frontend state, and computes patches from that change.run_requested_timestamp
changed. This patch is matched by our wildcard as a side effect.This change is mostly internal. Right now I want to mimick the old behaviour with respect to #220, but after this PR, it will be easier to control this behaviour. Instead of having a queue of executions, we could see this as: "this is the set of cells that still needs to be executed". Then we can improve #220, and we could allow you to add new cells while older cells are still queued, and execute that new cell faster, before waiting for all cells to be done.
This also means that Shift+Enter will be slightly faster! Because it avoids the second round trip/
TODO
search for:
test for