mengw15 opened a new issue, #8711: URL: https://github.com/apache/texera/issues/8711
`WsClientPromptCommand` carries the workspace's current warehouse pick, and the handler applies it to the agent's delegate config before running (#8586). The execution tools read that config lazily, at each tool call, and prompts are not serialized — `sendMessage` has no state guard and the WebSocket handler accepts a new prompt while a run is in progress. So a prompt that arrives mid-run re-points the warehouse for the rest of the run already going: 1. A chat prompt starts a task while warehouse A is selected; the agent begins executing operators, writing into A. 2. The user picks warehouse B in the canvas dropdown. 3. The user sends anything else to the agent — operator feedback is the reachable case, since the interaction panel gates only on connectivity, not on agent state. 4. The remaining executions of the *first* task write into B. Nothing crosses a user boundary — the ownership check still applies — but a run's output is split across two warehouses without the user asking for that. Related, under the same interleaving: a prompt sent while the workspace has no pick (during the initial load, or right after a workflow switch clears it) clears the agent's warehouse, and the rest of that run is refused by the backend requirement. The same interleaving already corrupts `head`, `abortController`, `currentMessageId` and the streaming callback, so serializing prompts — or snapshotting the execution config per run — would address a class of problems rather than only this one. The reason to track it separately is that this is the first one that writes *data* somewhere unexpected. Part of #6870. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
