migration-test: a green run on any branch closes the tracking issue for a bug still on main

[rafaelgiln]

migration-test.yml closes its failure-tracking issue on any green run, from any ref:

- name: Close issue on success
  if: success()

Nothing checks github.ref, so a green workflow_dispatch run of a branch closes the issue that tracks a bug still present on main.

Observed, not hypothesised

While validating the fix for #1143 (the racy execute_flow_ui assertion):

1. Run #116 failed and opened Langflow Migration Test Failed (latest → nightly) #1143 — correct.
2. Run #117 was dispatched on fix/issue-1143-playground-reply-stream-race, passed, and its Close issue on success step closed Langflow Migration Test Failed (latest → nightly) #1143 at 17:29:23 — while the fix was still unmerged and main still carried the racy assertion.

I reopened it by hand. Nothing in the tracker recorded that the closure was based on a branch's code.

Why it matters beyond the tidying

Validating a fix by dispatching the workflow on its own branch is the recommended way to prove these changes — #1139 and #1141 could only be proven that way, and the same is true of anything touching this workflow's report or Playwright steps. So the practice that produces the best evidence is also the one that silently closes the tracking issue. Anyone reading the tracker afterwards sees a closed issue and a red main.

It is the same shape as #1120, #1141 and #1143: one signal (a green run) read as proof of a different claim (fixed on the default branch).

Suggested fix

- name: Close issue on success
  if: success() && github.ref == 'refs/heads/main'

A green branch run then proves the fix without touching the tracker, and only a scheduled or main run closes the issue. Consider whether the same guard belongs on Create or update issue on failure — a red branch run currently files (or comments on) a tracking issue for code that is not on main either, which is arguably useful but should be a deliberate choice, and if kept it should say which ref it ran on.

Both jobs are affected — migration-test (migration-test.yml:295) and migration-test-compose (:~688) each have their own copy of the step.

Coordination

PR #793 ("stop migration-test jobs from closing each other's failure issues") is open and edits these exact blocks — it swaps the label each job filters on (migration-test-api / migration-test-compose). It does not touch the if: condition, so the two changes are compatible, but they collide textually. Land one and rebase the other; #793 has been open since 2026-07-28 and its mergeability against current main is already unknown.

Done when

• A green run on a branch does not close the tracking issue
• A green run on main (scheduled or dispatched) still closes it
• Both jobs carry the same rule
• An explicit decision on the failure path: keep filing from branches, or scope that too — and if kept, name the ref in the issue body