Here is the last time we did an architectural review of this project. We came up with this document - /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/VS_CODE_ARCHITECTURE.md. My understanding is over a number of commits we have managed to move more code from these plugins into the upstream Galaxy Tool Util packages. Can you review this document and verify details and see what needs to be updated if anything?
We’re trying to converge a Python toolkit for managing Galaxy workflows tracking across a few places with a TypeScript toolkit tracked in this branch.
The Python portions are in:
- Low-level Galaxy Python modeling in gxformat2 project: /Users/jxc755/projects/worktrees/gxformat2/branch/abstraction_applications
- Galaxy Backend/CLI Pieces: /Users/jxc755/projects/worktrees/galaxy/branch/wf_tool_state and described in: /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/CURRENT_STATE.md
- And a budding webapp in: /Users/jxc755/projects/repositories/gxwf-web
Can you review the connection validation code on the Python side and plan to replicate it here.
/Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/CURRENT_STATE.md is the state of what we’re working on and /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/PROBLEM_AND_GOAL.md is what we’re working toward.
Lets add a deliverable to PROBLEM_AND_GOAL. I want full support for gxformat2 in the IWC pipeline, CI, website, etc…
Read and follow directions in /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/MEMORY.md to get up and running. Please review doc/source/dev/wf_tooling.md for some understanding of why things are inconsistent. I think I’d like to rename the CLI methods:
- galaxy-workflow-validate -> gxwf-state-validate
- galaxy-workflow-clean-stale-state -> gxwf-state-clean
- galaxy-workflow-roundtrip-validate -> gxwf-roundtrip-validate
- galaxy-workflow-export-format2 -> gxwf-to-format2-stateful
Then I’d like to start with the gxformat2 and work on making the workflows cohesive in the sense that this work feels like taking that work and adding state to the mix.
- I’d like to converge gxwf-to-format2 and gxwf-to-format2-stateful in CLI options and structure, etc… to whatever degree possible (maybe this is tough though).
- I’d like to implement gxwf-to-native-stateful on this side of things to reflect gxwf-to-native in gxformat2. Obviously it would try to reuse and callback and the functionality developed for roundtrip validate - so if we could refactor that out for reuse.
- I’d also like to make a gxwf-lint-stateful that extends the functionality in gxformat2 but to include the stateful validation (the functionality from gxwf-state-valdiate).
Can you do some research and draw up a large plan for all of this. None of the code on the galaxy side has ever reached release state so we don’t have worry about backward compatibility and in fact we should work hard to get the best abstractions and cleanest code we can now while we have freedom. The planning can and probably should include developments on the gxformat2 side of things.
Can you review 35819900a2d0bfb0cf74f019f453d194a2bd2285 in /Users/jxc755/projects/worktrees/gxformat2/branch/docs. It has setup some declarative testing for the normalized versions of the two workflow models. I’d like to extend the models we added in 089442769db2100771cce5d4029079cefe43fa5c - with normalized versions that mirror what we did in gxformat2 and that can rerun the declarative tests we setup there.
Can you draw up a plan for this on this side and let me know if there is anything we can do on the gxformat2 side of things to improve the ease of reuse of those models here. We already are syncing artifacts from gxformat2 and I think we will just want to expand that for testing here.
Can you review the “validation” modules in /Users/jxc755/projects/worktrees/galaxy/branch/wf_tool_state/lib/galaxy/tool_util/workflow_state - this project is trying to replicate a lot of Python functionality in TypeScript. My understanding of the workflow validation is something like
Dispatch on Type:
-
If Native, validate against the native schema and then walk the steps and validate the “tool_state” in each step against a dynamic schema of type workflow_state_native
-
If format2, validate against format2 schema then walk the steps and validate the the “state” against the workflow_step and then migrate connections into the state and validate that against workflow_step_linked tool state.
I’d like to expand our validation CLI in here to do these operations also. Can you come up with a plan for this. We have a CLI that does the out workflow shape validation and we have the ability to generate these dynamic models, and we have tool cache reading code that can use the tool structures bridging the workflows and the dynamic models.
Point at particular workflows.
So I think /Users/jxc755/projects/repositories/galaxy-hub/ (https://github.com/galaxyproject/galaxy-hub) -> galaxyproject.org and /Users/jxc755/projects/repositories/iwc/website (https://github.com/galaxyproject/iwc) -> https://iwc.galaxyproject.org/. Represent the most updated Galaxy documentation styling / design principles. Galaxy itself /Users/jxc755/projects/repositories/galaxy/client -> https://github.com/galaxyproject/galaxy usegalaxy.org has a related styling that these are sort of derived from. Can you have three subagents research the styling pipelines, decisions, principles, colors, typing, etc… for each of these projects and write out three reports on the styling in DESIGN_IWC.md DESIGN_HUB.md, and DESIGN_CORE.md.
Please read “/Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/GXWF AGENT.md” for context.
I’d love for the APIs to be destructive and then the current behavior preserved with a dry run option. Can you build a plan to do this?
Please read “/Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/GXWF_AGENT.md” for context. We did this awhile ago and it went really well /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/old/CONNECTION_VALIDATION.md. Adding connection validation logic to the Python project before we knew we’d have a TypeScript version of all of this code.
We started working on this project by introducing the workflow-graph package that will be used here for some of those higher level abstractions and shared with the Galaxy code. That work was scoped out in /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/TS_CONNECTION_REFACTOR_IN_GX_PLAN.md and is only half done. I want to start working on the connection validation at the CLI level in here based on it though. Before we get there - can we tweak the Galaxy-side testing of connection related things to allow interopable tests. What are some ideas you can come up with for doing that?
Please use this branch /Users/jxc755/projects/worktrees/galaxy/branch/wf_tool_state for Galaxy side exploration.
We were working on the /Users/jxc755/projects/repositories/galaxy-brain/vault/projects/workflow_state/WF_VIZ_1_PLAN.md and triaging the unresolved questions.
❯
What are the remaining unresolved questions - anything we should discuss or have a subagent research?
⏺
Quick triage of the four:
- Ribbons (multi-strand rendering) in B3 vs B7.
Not a research question — design call. The plan already leans toward B7 follow-up (width-encoded single edges first, validate, then add ribbons behind a flag). I’d just commit to that. The risk of doing it in B3 is shipping a visual encoding nobody’s looked at yet on real workflows; better to get the simple version in front of users first.
—annotate-connections
becoming the default.
Effectively settled — “opt-in for at least one release cycle.” I’d remove this from the open list; it’s a future re-decision, not an open question now.
- Python parity for
map_depth
/
reduction
.
This is the genuinely researchable one and the most consequential. Multi-repo trace: where does reduction detection actually live in Galaxy (
galaxy.tool_util.workflow_state
?), what’s its existing output shape, is there a parallel Python builder we’d want to extend, and is the cheap “always emit
map_depth: 0, reduction: false
defaults” approach feasible on the Python side without ripping into the validator? Worth a subagent.
- CDN bumps for
cytoscape.html
.
Lower stakes but research-able — current
cytoscape.js
/
tippy.js
/
popper
versions, whether there are breaking API changes between the 2018-era pins and current, whether the existing template’s
cy.style().selector(…)
calls and tippy options still work. Smaller scope; could ride along with (3) or be its own thing.
Recommendation
You and I decide (1) right now
— propose: B7 follow-up, single-edge width encoding in B3. -
Drop (2)
from the open list. -
Spawn one subagent on (3)
— it needs git/grep across the Galaxy repo and possibly the Python
gxformat2
repo, plus understanding of how reduction is currently surfaced. Not a quick lookup. -
Bundle (4) into the same agent
as a secondary task, or skip — your call. CDN audit is bounded and doesn’t block any TS work; could land whenever. Want me to launch the (3)+(4) research agent? And want me to lock in the B7 deferral for (1)?
Harden YAML Tools:
YAML tools introduced in “/Users/jxc755/projects/repositories/galaxy-brain/vault/research/PR 19434 - User Defined Tools.md” and new Tool Request API introduced in “/Users/jxc755/projects/repositories/galaxy-brain/vault/research/PR 20935 - Tool Request API.md” / “/Users/jxc755/projects/repositories/galaxy-brain/vault/research/PR 21842 - Tool Execution Migrated to api jobs.md” . I introduced a new backend for their execution in “/Users/jxc755/projects/repositories/galaxy-brain/vault/research/PR 21828 - YAML Tool Hardening and Tool State.md”.
So much of Galaxy goes through basic.py and use the older-style recording of job parameters in the database - tool re-running, history import/export, job display in the UI, workflow extraction from the history.
As part of the tool request work we’re trying to mostly bypass basic.py and used structured state to reason about tool state at some of these parts but not all. Like we haven’t used the stored and validated job description in workflow extraction, tool re-running, history import/export, the job display UI. The subtle differences in job representation and not using them uniformly seems like it would be rife for errors.
I think to harden YAML tools - I would like to see history import/export, workflow extraction tests use a wide variety of YAML tools and work end-to-end. We have good coverage of these things for XML tools at the API layer - but I would like to also see it at the E2E test level to ensure the new tool form and how it consumes the new API are all okay. API tests for history import/export would be great - extracting workflows after history import/export - again a combination of tests I think we have for XML tools but not for YAML tools.
Before we had the tool request API (20935), the under-specified API kept me up at night. Before 21828 - I was worried we weren’t using the structured state at runtime or recording it and before 21842 - I was worried we were using the new structured API from the GUI. I’m now feeling pretty good about the runtime from the form through the first job - but the difference between how we use the record of what was run vs how use it after the fact are causing me the stress.