Summary
When a parent workflow calls subWorkflow.run(...) (e.g. AskUserWorkflow.run from @loopstack/hitl), the sub-workflow runs correctly but its UI is not visible inside the parent's Studio run view. The parent's view stays blank while the user is being asked to interact with the sub-workflow. As a result, every HITL flow built by reading the public docs first appears broken.
Steps to reproduce
- Build a parent workflow that calls
this.askUser.run({ question: '...' }, { callback: { transition: 'callback' } }).
- Run the parent workflow in Studio.
Expected behaviour
The sub-workflow's question UI is rendered inside the parent's run view by default, so the user can answer without leaving the parent's page.
Actual behaviour
The parent's run view is empty. The sub-workflow runs in its own context, accessible only via its own run page. Users cannot tell the parent is waiting on them.
Affected area
- Package(s):
@loopstack/common (orchestrator), @loopstack/hitl, every consumer of BaseWorkflow.run
Additional context
Surfaced during a benchmark agent session. The HITL pattern docs describe the .run() + callback flow but never mention that the parent has to take an extra step for the child to appear in its view. The fix (manual LinkDocument save with embed: true) is only discoverable by reading the registry example source.
Summary
When a parent workflow calls
subWorkflow.run(...)(e.g.AskUserWorkflow.runfrom@loopstack/hitl), the sub-workflow runs correctly but its UI is not visible inside the parent's Studio run view. The parent's view stays blank while the user is being asked to interact with the sub-workflow. As a result, every HITL flow built by reading the public docs first appears broken.Steps to reproduce
this.askUser.run({ question: '...' }, { callback: { transition: 'callback' } }).Expected behaviour
The sub-workflow's question UI is rendered inside the parent's run view by default, so the user can answer without leaving the parent's page.
Actual behaviour
The parent's run view is empty. The sub-workflow runs in its own context, accessible only via its own run page. Users cannot tell the parent is waiting on them.
Affected area
@loopstack/common(orchestrator),@loopstack/hitl, every consumer ofBaseWorkflow.runAdditional context
Surfaced during a benchmark agent session. The HITL pattern docs describe the
.run()+ callback flow but never mention that the parent has to take an extra step for the child to appear in its view. The fix (manualLinkDocumentsave withembed: true) is only discoverable by reading the registry example source.