GitHub user eugenegujing edited a discussion: What should "Import Workflow" do?
## Background The workspace toolbar has an "Import Workflow" button that loads a workflow JSON file into the currently opened workflow. Its behavior is partly buggy (reported in #6846): besides replacing the canvas content, it fabricates the workflow's metadata from scratch — it sets `wid` to undefined and renames the workflow to the imported file's name, and it resets `description` and the published state. The `wid: undefined` part has clear bad consequences. The auto-persist that fires after the import sends no wid to `/workflow/persist`, so the backend inserts a brand-new workflow: every import silently adds a duplicate workflow to the user's list, and the editor's URL silently switches to that duplicate. Meanwhile the originally opened workflow's shared-editing session was already mutated by the import, so the user ends up with two workflows carrying the imported content — the original (under its old name) and the duplicate (named after the file). Here is an example: Open a workflow A that already has content, then use the workspace toolbar's "Import Workflow" button to import a workflow file B. Two things go wrong: the editor silently navigates to a brand-new workflow created from B (a duplicate entry appears in the workflow list), and workflow A's original content is also totally replaced by B's content. The user ends up with two workflows both holding B's content, and A's original content is gone from A. https://github.com/user-attachments/assets/2fc519ce-194b-424f-bb2a-965f9a720c29 ## The question for the community Fixing the duplicate requires deciding what the import's intended semantics are, and that is a user-facing behavior change, so I would like to hear opinions before finalizing it. ## My proposal Import should replace only the content of the currently opened workflow, and everything else should stay as it is in that workflow: keep its `wid` (so auto-persist updates it in place instead of inserting a duplicate), keep its name (no more renaming to the file name), and keep its `description` and published state (today they are silently reset — importing into a published workflow unpublishes it). Concretely, the imported workflow object would be built as `{ ...getWorkflowMetadata(), content: importedContent }` instead of a fabricated object. The pre-import content remains recoverable through the version history, since the in-place save records a version like any other edit. In addition, I think a confirmation UI is necessary. Since import directly overwrites the canvas, a user who already has content in the current workflow should see a dialog telling them the existing content will be overwritten by the imported file, and the import should proceed only after they confirm. If the current workflow is empty, the import can proceed without asking. Today there is no warning at all — one click silently destroys the current canvas. Two consequences worth calling out: 1. Import no longer renames the workflow to the imported file's name. In a brand-new unsaved workspace, the workflow keeps the default "Untitled Workflow" name instead of taking the file name. 2. Users who actually want "create a new workflow from a file" are not losing anything: the dashboard workflow-list page already has an upload button that does exactly that (single JSON or a zip of several), names the new workflow after the file, and is unaffected by this change. ## Alternative considered Make the toolbar import replace the workflow entirely — treat the file as a whole new workflow that takes over, name included. I don't think this is the right direction, because the dashboard upload button already provides exactly that "create a new workflow from a file" feature, and duplicating it inside the workspace would leave no way to import content into an existing workflow. I have a working fix with unit tests ready following the proposal above (the confirmation dialog could be part of the same PR or a follow-up) and will open a PR referencing this discussion and #6846. Feedback on the proposal is very welcome. GitHub link: https://github.com/apache/texera/discussions/6873 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
