fix(web): tool auto-resolution + workspace-scoped ToolShed URL (on top of #91)

[jmchilton]

Builds on #91 (list-form step resolution, native tool_state routing, gxformat2 connection completion). This PR = #91 + a tool-util bump and the client-side fixes that make web-mode tool resolution actually work. Until #91 merges its commits show here too; afterward this reduces to the two new commits.

What's new on top of #91

chore(deps): bump @galaxy-tool-util/* 1.8.0 → 1.8.2

1.8.2 strips in-memory-only derived fields (connected_paths, unique_tools) at serialize time, so clean/convert output no longer leaks them as stray keys that downstream schema validators reject.

fix(web): enable tool auto-resolution + workspace-scoped ToolShed URL

Two related gaps that left web-mode tool resolution non-functional:

• (A) Browser language clients now pass toolAutoResolution, matching the node desktop clients (client/src/extension.ts). Without it the web server's autoResolutionEnabled stayed false, so opening a workflow never auto-fetched/cached its tools — no tool_state completion and a spurious "uncached tool_state" diagnostic. One-line parity fix.
• (B) galaxyWorkflows.toolShed.url scope machine → window so it can be set in workspace .vscode/settings.json (machine scope is user-settings-only). Lets a repo pin its ToolShed and unblocks web, where machine-scoped settings don't reach the language worker. toolCache.directory stays machine (a real filesystem path).

A and B are complementary: A arms the fetch-on-open trigger, B lets the URL reach the worker.

Not included

• Single-client PopulateToolCacheCommand (native-only) — fix lives in web_tool_cache_wiring.
• ToolShed CORS for browser fetch is a ToolShed-server limitation (needs a CORS-enabled shed or proxy), not addressable here.

Tests

• Server: 456 passing. Client: 58 passing. Lint clean.
• Manually verified in vscode-test-web: opening a .gxwf.yml now auto-resolves its tool, clears the diagnostic, and tool_state select/property-name completions work (captured for docs).

🤖 Generated with Claude Code

[davelopez]

A couple of things I noticed in the base PR (#91):

• The opening IWC workflow populates empty cache from ToolShed integration test is silently skipped or waits indefinitely (See https://github.com/davelopez/galaxy-workflows-vscode/actions/runs/27825642994/job/82349230624?pr=92#step:11:219). If I manually run pnpm run test:e2e, I can observe that when this test is running, it just waits for some seconds and then continues with the next test. But if I click the Tool cache icon in the status bar to populate the cache, then the test passes, so something is preventing the auto-cache.

  

• Given this example:

  class: GalaxyWorkflow
  inputs:
    input_data:
      type: data
  outputs: {}
  steps:
    fastp_step:
      tool_id: toolshed.g2.bx.psu.edu/repos/iuc/fastp/fastp
      tool_version: 1.1.0+galaxy0
      state:
        duplicated_reads: "" <--- using a string here is not valid, but crashes instead of failing validation

  This is the error message in the stacktrace:
  Error: Container parameter "filter_options" (gx_section) has string value — expected dict/list. This indicates legacy parameter encoding which is not supported. Decode the workflow first.

Thank you so much for all the fixes and improvements. Whenever you are satisfied with the features, let me know, and we can publish a new release 🚀

[jmchilton]

🤖 Posted by Claude (AI assistant) on jmchilton's behalf — not written by them personally.

Thanks David — both addressed, and the second one ended up getting fixed at the right level upstream rather than worked around here.

1. Auto-cache test silently skipping

Root cause: the test opened the shared fixture URI, but when that document was already open VS Code reused it and onDidOpen never fired — so scheduleResolution never ran and the test fell through to its offline-skip. Fixed in 4bcb75e:

• Opens a fresh temp copy so onDidOpen always fires (matches the manual "Populate Tool Cache" path you found works).
• Hardened the gate: getToolCacheStatus now reports autoResolutionEnabled, and the test asserts it true up front — so a gate regression fails loudly instead of masquerading as "offline". (The network-dependent part still skips when genuinely offline, which is the only remaining skip.)
• onDidOpen no longer swallows a rejected resolution — it logs.

2. String-valued container crashing instead of failing validation

You're right that crashing was wrong. Rather than catch-and-convert in the extension, I fixed the contract violation in @galaxy-tool-util itself, since that's where the walker and the "validators return diagnostics" contract live: jmchilton/galaxy-tool-util-ts#144 (released in 1.9.0). The walker now throws a typed StringContainerError (carrying the param path + container type, mirroring the existing UnknownKeyError), and the diagnostic-returning validators map it to a located ToolStateDiagnostic instead of letting it escape. Conversion paths still throw, and the message is unchanged so the CLI/web message.includes(...) consumers keep working.

Downstream then just consumes the diagnostic: this PR bumps to 1.9.0 (ea65cb7) and removes the interim regex/try-catch workaround (cee0142). Your fastp example now surfaces a clean error on the offending param instead of crashing the pass.

Server suite 460 green, client 58 green, lint clean.

[davelopez]

Now it is fixed! Great, thanks!