Thanks a lot @fe145f9fb2a1f6b and @mlauber71 for the pointers.
We did explore the batch‑chain route (parent workflow calling child workflows via batch), and while it does run, our business constraints don’t allow us to rely on batch orchestration for this use case. We also accounted for batch‑mode nuances—like KNIME defaulting to a different “standard” workspace unless -data is provided—and tested both -workflowDir/-workflowFile and -workflow.variable paths/flags. Still no luck for our scenario.
On the “call‑workflow” path, we tried:
-
Passing the workflow path as a flow variable and binding it in Call Workflow (Services)
-
Table Creator → Call Workflow (Table Based)
-
Mountpoint Connector
-
Table to Variable → Variable Expressions → Variable to Path
-
Various combinations of the above
The blocker we keep hitting is that at runtime the path we pass gets converted to an FSLocationVariableType and rewritten to a relative path (e.g., knime://knime.workflow/...). That relative path becomes unresolved when launched via batch, and the call fails. We are looking for a way to prevent this auto‑conversion or to force absolute resolution in the callee. [knime.github.io], [forum.knime.com]
If you (or anyone) knows how to (a) stop the FSLocation auto‑conversion, (b) force absolute paths end‑to‑end in Call Workflow nodes, or (c) ensure the same file‑system context is transferred to the callee so the FSLocation resolves correctly, we would really appreciate the specifics. For reference, we have noted that Call Workflow (Table Based) often converts incoming path/URI variables to strings, and that it can accept a File System Connection port—so any “known good” settings there would also help. [hub.knime.com]