You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An OMP foreground turn starts a child task that is intentionally detached so it can continue in the background. The user then presses Stop on the foreground turn while that detached child may still be running a native or Paseo host tool.
Core cancellation work in #5243, merged as 90737e1, makes OMP stopReason: "aborted" end the foreground turn as canceled and fences a stale provider-idle response. It intentionally retains the current behavior of terminalizing all running child cards. The earlier #4921 proposed preserving detached children, but its review identified an unsafe split: the child descriptor remained running while shared host-tool cleanup could still abort the child's in-flight tool.
The community omp-plugin currently follows the conservative behavior: canceling the parent terminalizes all of its subsessions. We are not changing that without a product contract.
Decision requested
When a user presses Stop on a foreground turn, should Paseo:
Cancel detached children atomically. The foreground turn and every child it owns each emit exactly one canceled terminal state; in-flight child tools are canceled; no late child/tool event can revive or mutate the canceled work; a later parent turn remains healthy.
Preserve detached children with independent ownership. The foreground turn emits exactly one canceled terminal state, while each detached child remains running and independently fetchable; host-tool and other resources used by that child are not cleared or aborted with the parent; the child terminalizes independently; late child events cannot alter the canceled parent or a later turn.
Preserving only the child/session descriptor is not sufficient. The product contract would also need to define ownership and lifetime for shared host-tool state, permissions, tool calls, subscriptions, and cleanup so the UI cannot show a running detached child whose underlying work was already aborted.
Which behavior should the provider protocol and bundled OMP provider guarantee? If preservation is desired, should detached children receive an explicit independent resource owner before foreground cancellation completes?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Workflow
An OMP foreground turn starts a child task that is intentionally detached so it can continue in the background. The user then presses Stop on the foreground turn while that detached child may still be running a native or Paseo host tool.
Core cancellation work in #5243, merged as
90737e1, makes OMPstopReason: "aborted"end the foreground turn as canceled and fences a stale provider-idle response. It intentionally retains the current behavior of terminalizing all running child cards. The earlier #4921 proposed preserving detached children, but its review identified an unsafe split: the child descriptor remained running while shared host-tool cleanup could still abort the child's in-flight tool.The community
omp-plugincurrently follows the conservative behavior: canceling the parent terminalizes all of its subsessions. We are not changing that without a product contract.Decision requested
When a user presses Stop on a foreground turn, should Paseo:
Preserving only the child/session descriptor is not sufficient. The product contract would also need to define ownership and lifetime for shared host-tool state, permissions, tool calls, subscriptions, and cleanup so the UI cannot show a running detached child whose underlying work was already aborted.
Which behavior should the provider protocol and bundled OMP provider guarantee? If preservation is desired, should detached children receive an explicit independent resource owner before foreground cancellation completes?
All reactions