🤖 Drafted by Claude (AI assistant) on John Chilton's behalf — not authored by John personally.
Scope: bring docs/configure.rst back to internal completeness now that PR #458
adds a capability snapshot to the relay. These are consistency/maintenance
additions describing only what this PR already does — not new design.
Speculative documentation is explicitly excluded (see "Out of scope" below): the Galaxy-side BYOC consumer contract (how Galaxy fetches/interprets the
Target: galaxyproject/pulsar#458 (branch pulsar-capabilities).
This plan combines two coupled changes:
PulsarApp.__init__ for every deployment mode, but is only
ever consumed by the relay publish path). Also incidentally deletes review issue #1
(the stale get_capabilities comment lives in the method Part A removes).
Reviewing the executive summary for Galaxy's workflow state validation work (for GCC2026 talk prep). The original summary made strong claims about competing projects that needed fact-checking.
| # Workflow Semantics - Discovered Facts | |
| # Each record: test (identifier), fact (behavioral description), context (utility for a semantics doc) | |
| # ============================================================================= | |
| # OPTIONAL DATA INPUTS | |
| # ============================================================================= | |
| - test: test_workflows.py::test_run_with_optional_data_specified_to_multi_data | |
| fact: Optional data input when provided is consumed normally by multi-data tool. | |
| context: Positive baseline example for optional data input behavior. |
"New Chat" button in ChatHistoryPanel sidebar is a no-op when user is already on /chatgxy (no exchange ID in URL).
ChatHistoryPanel.vue:67-75 does router.push("/chatgxy") to start a new chat. Vue Router ignores navigation to the current route, so nothing happens when already at /chatgxy.
Currently BatchDataInstance (line 534) and BatchDataInstanceInternal (line 883) are simple {src, id} models. Add map_over_type: Optional[str] = None to both. Use Optional[str] — consistent with how collection_type is modeled elsewhere.
This is the core request-layer gap — map_over_type is how clients express subcollection mapping intent in batch values, but the schema doesn't model it.
We implemented a SidebarList extraction in 79678d08d5. Can we evaluate the refactoring plan (CONVERGE_CHAT_HISTORY_PLAN.md) versus just parameterizing ChatHistoryPanel and using it in both places? Is that viable? What are the blockers? What results in better structure?
Approach A — Synthetic Tool Steps: During CWL import, inject Galaxy's bundled pick_value expression tool as a synthetic workflow step for each workflow output that uses pickValue. The tool already handles first_non_null (via first_or_error) and the_only_non_null (via only). Parser-only change — no model migrations, no runtime changes. Does NOT cover all_non_null (tool can't return arrays/collections). Estimated 1-2 files touched in parser.py.
Approach B — Native Framework Support: Add a pick_value column to the WorkflowOutput model, create duplicate-label WorkflowOutput objects across source steps, then post-process pickValue semantics in run.py after all steps complete. Covers all three modes including all_non_null. Requires DB migration, model changes, parser changes, import changes, runtime changes, and export changes. Estimated 5-7 files touched.
Two conformance tests require Docker container execution:
test_conformance_v1_0_dockeroutputdir — Tool docker-output-dir.cwl uses dockerOutputDirectory: /other, runs touch /other/thing. Without Docker, /other doesn't exist.test_conformance_v1_0_docker_entrypoint — Tool docker-run-cmd.cwl with bash:4.4.12 image. Command is -c 'echo moo' > cow relying on Docker ENTRYPOINT (bash). Without Docker, -c is "command not found".