Stuck in bad snapshot state

[taylordowns2000]

Problem

1. We get stuck in a bad snapshot state
2. When I try to "reset to latest snapshot", the workflow collapses into itself like a neutron star

when opening a workflow

when reseting to try to get back to editable state

Discussion

Taylor Downs: https://openfn.slack.com/archives/C05KZNPEJFN/p1761119894314279
🦆 i'm starting to see why there's that weird "revert to latest" button
is this a deep issue, or simply something that hasn't been wired up yet?
my workflow frequently gets into an uneditable/unsaveable state

@midigofrank :
That’s the part I need to discuss with Stu. They are somehow related.
There is a known issue that when someone else updates the workflow you might get stuck because you have a reference to the old snapshot.
Currently when you edit the workflow, whether in an invalid state or valid state, that state is saved somewhere and the only where to get out of it is to “reset to latest”

@stuartc :
It's probably not "deep", but will require some careful steps to recreate it, we need to track what is being sent to the browser (use the Redux Devtools extension in Chromium browsers, you can see the WorkflowStore state).
Make notes please, of the state and logic that determines why it's stopping you from saving, this applies to err'ybody. please make an issue.

The solution should be something around the lines of "oh we're not always sending this", or "an update to the ydoc is setting something to null" etc. OR it's something around after saving that the "real" workflow is somehow different and the ydoc isn't being updated properly (less likely but not impossible). Or it's a timing issue, which I hope it's not because a lot of care went into getting things to happen in a way it doesn't matter.

Currently when you edit the workflow, whether in an invalid state or valid state, that state is saved somewhere and the only where to get out of it is to “reset to latest”

Re ☝️ we persist the ydoc to a table called document_states , this way if someone drops their connection or closes their machine, or two people work together and one carries on (without saving the workflow) and disconnects before someone comes back, the ydoc is always up to date no matter what. So we technically have another workflow being saved.

[taylordowns2000]

@stuartc , @midigofrank , this seems to fix the "one editor saving locks the other out" issue:

diff --git a/lib/lightning_web/channels/workflow_channel.ex b/lib/lightning_web/channels/workflow_channel.ex
index bf6d8e5758..543d62a74f 100644
--- a/lib/lightning_web/channels/workflow_channel.ex
+++ b/lib/lightning_web/channels/workflow_channel.ex
@@ -165,6 +165,12 @@ defmodule LightningWeb.WorkflowChannel do
 
     with :ok <- authorize_edit_workflow(socket),
          {:ok, workflow} <- Session.save_workflow(session_pid, user) do

+      # Broadcast the new lock_version to all users in the channel
+      # so they can update their latestSnapshotLockVersion in SessionContextStore
+      broadcast_from!(socket, "workflow_saved", %{
+        latest_snapshot_lock_version: workflow.lock_version
+      })

I have not fixed the neutron star collapse or the decapitated workflow bug, but moving on to those next

[taylordowns2000]

wip...

.context/taylor/analysis/race-condition-diagnosis.md

[taylordowns2000]

fixed in #3852