Convert workflow extraction interface to Vue

[guerler]

The last non-data display related mako in Galaxy is the build_from_current_history mako. This mako and its associated controller endpoint should be converted to FastAPI and Vue.

[guerler]

Having discussed this with @bgruening, the more reasonable alternative here might be to extract the workflow and display it in the workflow editor without having to display the list and selection options for the datasets.

[mvdbeek]

I don't know if that's feasible for large histories where you might get a lot of crap (see the check all <-> uncheck all). if your goal is to remove makos without further changes I'd just convert it to vue ?

[jmchilton]

I mentioned at the backend meeting I would post about the API for extracting workflows. Here is code for POST /api/workflows if from_history_id is included in the request:

        if "from_history_id" in payload:
            from_history_id = payload.get("from_history_id")
            from_history_id = self.decode_id(from_history_id)
            history = self.history_manager.get_accessible(from_history_id, trans.user, current_history=trans.history)

            job_ids = [self.decode_id(_) for _ in payload.get("job_ids", [])]
            dataset_ids = payload.get("dataset_ids", [])
            dataset_collection_ids = payload.get("dataset_collection_ids", [])
            workflow_name = payload["workflow_name"]
            stored_workflow = extract_workflow(
                trans=trans,
                user=trans.user,
                history=history,
                job_ids=job_ids,
                dataset_ids=dataset_ids,
                dataset_collection_ids=dataset_collection_ids,
                workflow_name=workflow_name,
            )
            item = stored_workflow.to_dict(value_mapper={"id": trans.security.encode_id})
            item["url"] = url_for("workflow", id=item["id"])
            return item

Here is the webapps controller code - it is relatively the same. I refactored it a decade ago to start to write workflow extraction test cases.

            # If there is just one dataset name selected or one dataset collection, these
            # come through as string types instead of lists. xref #3247.
            dataset_names = util.listify(dataset_names)
            dataset_collection_names = util.listify(dataset_collection_names)
            stored_workflow = extract_workflow(
                trans,
                user=user,
                job_ids=job_ids,
                dataset_ids=dataset_ids,
                dataset_collection_ids=dataset_collection_ids,
                workflow_name=workflow_name,
                dataset_names=dataset_names,
                dataset_collection_names=dataset_collection_names,
            )
            # Index page with message
            workflow_id = trans.security.encode_id(stored_workflow.id)
            edit_url = url_for(f"/workflows/edit?id={workflow_id}")
            run_url = url_for(f"/workflows/run?id={workflow_id}")
            return trans.show_message(
                f'Workflow "{escape(workflow_name)}" created from current history. '
                f'You can <a href="{edit_url}" target="_parent">edit</a> or <a href="{run_url}" target="_parent">run</a> the workflow.'
            )

We have a lot of good tests written around this code to ensure for instance that history import/export doesn't mess up workflow extraction as an indication that copying dataset logic, etc... is being preserved properly. I hope whatever is done here is done with care and done with an eye toward extension in the future. I think extracting workflows from histories is pretty much the core idea of Galaxy to my mind.

[guerler]

Thanks @jmchilton, and yes I agree. I would like us to use this endpoint as is and without augmenting it unnecessarily. Adding an additional filter option to export a history to a workflow on the basis of a subset of dataset and dataset collection entries might not be worthwhile imo. Instead users could easily create a copy of a history with a subset of entries and/or edit the workflow after it has been exported.

[jmchilton]

Claud and I drafted a detailed implementation plan for the Vue conversion of the workflow extraction interface:

📄 Vue Conversion Plan & Performance Analysis

Summary of approach:

1. New API endpoint: GET /api/histories/{history_id}/extraction_summary - exposes the existing summarize() function via FastAPI
2. Vue component: WorkflowExtraction.vue with job selection, input marking, and workflow naming
3. Minimal backend changes: Reuses existing extraction logic, no new database models

Key decisions:

• Preserves current UX (job selection + input marking) per @mvdbeek's feedback about large histories
• Skips pagination for MVP - performance analysis shows identical memory characteristics to current Mako implementation
  • I had Claude double check my concerns around memory https://gist.github.com/jmchilton/cf98d536a60bf394127fa3464fab0f92#memory-concern-mitigation.
• Recommends eager-loading optimization to reduce N+1 queries

Scope: ~800 LoC backend, ~600 LoC frontend. Removes last non-data-display Mako template.

Happy to help with implementation if this approach looks reasonable. The plan includes test coverage for both API and Vue components.

I am about to open 3 PRs that will add (1) add typing to the backend, (2) fix a bunch of issues around copied datasets during workflow extraction (multiple overlapping issues will be addressed), and (3) reuse a lot of workflow extraction API test plumbing to implement mirror tests for the UI. I also had Claude do multiple deep dives on the question of whether migrating these APIs from using HIDs to using IDs would fix any outstanding bugs - the answer I think is no but it would definitely set us up for like bringing portions of other histories (e.g. from job cache, etc...) and so that paired with a more responsive UI probably could solve some serious issues. I think the migration of this component could happen in parallel to both the testing changes I'm proposing and this HID -> ID API change.