Renaming a workflow locally leaves checkout metadata inconsistent after deploy; the next deploy deletes the workflow #1594

Renaming a workflow locally leaves checkout metadata inconsistent after deploy; the next deploy deletes the workflow

Summary

If you rename a workflow locally and deploy it, the deploy succeeds. But the CLI then writes the checkout file and project state under a new workflow id, while workflows/ stays on the old id. The next deploy of that workflow sees one workflow removed and a different one added, and Lightning deletes the workflow.

Steps to reproduce

1. Start with a checked-out project containing one workflow:

   workflows/my-workflow/my-workflow.yaml
     id: my-workflow
     name: My Workflow
   

2. Rename it locally by editing name:

   id: my-workflow
   name: My Workflow (renamed)

3. openfn project deploy. This succeeds and Lightning shows "My Workflow (renamed)" with the same uuid.

4. Look at the workspace:

   Location	Workflow id
   workflows/my-workflow/my-workflow.yaml	my-workflow
   .projects/<alias>.yaml (re-fetched state)	my-workflow-renamed
   checkout file forked_from	my-workflow-renamed: <hash>

5. Edit a step in the workflow and run openfn project deploy again.

Expected: the edit is deployed to the existing workflow.
Actual: the workflow is deleted from Lightning.

Why

• Ids aren't stored in Lightning. When the CLI builds a project from Lightning state, it derives each workflow id from its name (slugify(name)). After deploying, the CLI re-fetches the project and writes the checkout file and .projects/ state from it, so they pick up my-workflow-renamed. workflows/ isn't rewritten, so it keeps my-workflow.
• On the next deploy:
  • my-workflow (local) isn't in forked_from, so it's treated as a new workflow. Local workflows have no uuid, so it's sent as a create.
  • my-workflow-renamed (in forked_from) isn't on disk, so it's treated as removed and sent as a delete with the existing uuid.
  • Both have the name "My Workflow (renamed)", and to-app-state keys workflows by slugified name, so the delete overwrites the create. Lightning receives only the delete.

Notes

• Fix: renaming a workflow in git deletes it in Lightning #1587 adds guards in to-app-state: no delete for a uuid that's also being sent, and an error when two workflows map to the same key. With those guards this fails loudly instead of deleting data, but the workspace is still inconsistent. That PR also force-checks-out after deploy, which moves the workflow to a new folder. That isn't the behaviour we want, because user files stored in the workflow folder get orphaned.
• The underlying issue is that workflows are matched by a derived id rather than a stable identity. A proper fix probably means recording each workflow's uuid in the checkout file, keying forked_from by the local id, and matching workflows by uuid and version history rather than by id. That'll be tracked separately.
• Workaround (untested): openfn project pull after a rename deploy appears to bring the workspace back in sync, per Fix: renaming a workflow in git deletes it in Lightning #1587's QA notes.