fix(workflow): a save's response must not overwrite a newer local edit (WorkflowPersistService)
Maintainers usually reply within 1 day
@yangzhang75 is already working on this.
Since Sep 14, 2026.
Assessment
This issue has not been assessed yet.
Description
What happened?
Every save applies its response as the workflow's metadata: the workspace autosave (workspace.component.ts), the menu's own save (MenuComponent.persistWorkflow: rename, description, revert) and the Canvas -> Form View switch's save. Saves are sent one at a time since #8456, so a response can land after a newer local edit and overwrite it:
- Rename the workflow while an autosave is in flight: the autosave's response puts the old name back (until the rename's own save answers).
- Click Form View, then rename while the switch's save is out: the rename's save is queued behind the switch's, the switch navigates when its own save completes, and the full-page load aborts the rename's save (metadata edits do not emit
workflowChanged(), so the hand-over does not wait for them).
Deferred from #8456 on review (threads on menu.component.ts:692 and :231): the rule belongs in WorkflowPersistService, the one place every save goes through, not in one caller.
How to reproduce?
- Open a workflow on the operator canvas and make a graph edit (an autosave starts).
- Before it answers, rename the workflow in the title bar.
- The title flips back to the old name when the autosave's response is applied.
Or: click Form View and rename during the hand-over's save; the rename is lost.
Proposed fix
In WorkflowPersistService: do not apply (or hand back for applying) a response a newer local edit has overtaken, for every caller alike -- e.g. a revision per save, or apply from the response only the fields that still match what was sent; and let the Form View hand-over wait for the save queue to drain rather than for its own save only.
Version/Branch
main, after #8456.
Commit Hash
main
Browsers
All
Relevant log output
n/a
- Dominant language
- Scala
- Stars
- 316
- Forks
- 192
- Avg merge
- 4d 17h
- Merged PRs (30d)
- 141
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/texera
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
apache/texera#8775 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
apache/texera#8756 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/texera#8700 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
apache/texera#8682 · 5 comments ·
Maintainers usually reply within 1 day
-
JSONL File Scan reads a JSON null as the text "null"Possibly taken @CaroFernando claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
apache/texera#8674 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
[Rust][Flaky Test] multiple_deadlines_fire_in_order asserts a wall-clock gap instead of firing orderOpenCI/CD ⚒️ Flaky-tests 🐦
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
valkey-io/valkey-glide#7255 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
lichess-org/lila#21905 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 3 days