Fix: renaming a workflow in git deletes it in Lightning

[midigofrank]

Short Description

Deploying an edit to a workflow that was renamed in git deleted it from Lightning. Deploy now checks out the deployed project afterwards (as pull does), and the app state builder refuses to send a delete that would overwrite a workflow being deployed. In the cli-pull-action, I'm getting around this by creating the directory first: https://github.com/midigofrank/cli-pull-action/blob/v2-sync/action.yml

Fixes OFN-4760

Implementation Details

• Root cause: after a rename deploy the CLI re-fetched the project and derived the workflow id from the new name (my-workflow-renamed). checkout.yaml and .projects/ were updated but workflows/ wasn't, so the next deploy saw a delete of the new id plus an add of the old one. Both share a name, to-app-state keys workflows by slugified name, and the delete overwrote the add.
• deploy: after a successful workspace deploy (unless --no-checkout), run the checkout handler on the re-fetched project (force, track). A renamed workflow moves to a folder named after its new id; the old folder (or alias) is removed, as pull would do. Users can re-add an alias by renaming the folder.
  • File deploys and --workflow deploys keep the old behaviour (metadata files only), since workflows/ wasn't fully deployed and a forced checkout could overwrite local edits.
• to-app-state: never send a delete for a uuid that's also being sent, and throw if two workflows would map to the same key instead of silently dropping one.

QA Notes

• New tests: rename → deploy → edit → deploy keeps the workflow (same uuid, new name, edit applied); an aliased folder is replaced by the new-id folder; two to-app-state guard tests. All fail before the fix.
• With --no-checkout, a rename followed by an edit now fails with More than one workflow maps to … instead of deleting the workflow. openfn project pull fixes the workspace. Workspaces already drifted by older CLIs fail the same way.
• resources.yaml is now written the way pull writes it on workspace deploys.
• Step ids can still drift after a job rename (not addressed).
• Full-package ava runs segfault locally (also on the base commit); every test file passes individually.

AI Usage

• I have used Claude Code
• I have used another model
• I have not used AI

[josephjclark]

Weeeeelll jeez this is such a can of worms. I've been noodling around this all afternoon.

First off, we know that there are issues tracking workflow renames with the v2 CLI. Usually the difficulty is around preserving the UUID or local file system on a RENAME, rather than an addition or removal. That stuff still needs looking at and is unaffected by this PR.

The problem here SPECIFICALLY is when the workflow name field is changed on the file system.

As the PR suggests, this creates an inconsistent file system. Your workflows/ folder still uses the old workflow id derived from the old name, but the state and checkout files use the new workflow name (and don't actually track the workflow id at all).

So the idea here of basically checking out the project after a deploy... well yeah it sort of fixes the problem. But it's making me ask whether the current behaviour is right, and what are we even doing checking out after deploy anywya? There's just some local metadata that needs syncing, not a full checkout.

There's something else here too. I think we need to fix the merge code to enable it to detect a rename (via a bunch of heuristics and maybe a prompt).

And there are more problems. Like after renaming the workflow and checking out, the path to workflow.yaml changes. But that's disastrous if the repo has unit tests against the old workflow id, or if there are any automated scripts which run against the old id. And you'll get a big github diff right after the rename?

Those local workflow paths matter and things get a bit hairy after that rename.

I want to think about this some more. I think we're addressing the symptom, not the cause, and that makes me nervous.