Can't update ui in a worker

[femto]

this is from #6208 (comment),

I have another case, that when I submit in CustomTextArea,
and try to call llm, I have a Messages component above CustomTextArea,
so I need to first append this user's message to it, then call llm
to retrieve llm response to append to Messages again, when hit enter
in textarea, the ui just halts and after llm response will be both messages
append to Messages component. And the loading_indicator (the spinning
component wounldn't show). Any idea on that?

The component structure is like this, REPL has Messages and Input,
Input submit should update Messages(it's parent's components, so ui update
is happening in parent). Is it possible that child workers
will block parent's ui update? I tried first add user message first and then
immedicate call run_worker of calling llm, with no luck. The Messages component
's update_messages has self.mutate_reactive in it, which shouldn't be a problem.
If I return after adding user message and don't do call llm, then Messages immediately
shows user message.

Unfortunately I can't produce a small reproducible example,
if you want I want point you to my open source repository for the example,
and maybe schedule a session on how to set it up.(basically it's a cli agent
like claude code, has input to submit query).

I tried [Anatomy of a Textual User Interface]
example, and changed @work(thread=True) to @work ,and async def send_prompt,
change self.call_from_thread(response.update, response_content) to response.update(response_content)，
then it kind of reproduce my bug, the user message and response didn't show up for like 5 seconds,
and then user message and response suddenly shows up.
Shouldn't @work also at least run work in background and should update ui？

[TomJGooding]

https://textual.textualize.io/guide/workers/

In previous examples we used run_worker or the work decorator in conjunction with coroutines. This works well if you are using an async API like httpx, but if your API doesn't support async you may need to use threads.

[femto]

Hi, my llm call uses async streaming. This isn't the problem source.
You can change https://github.com/work(thread=True) to @work in [Anatomy of a Textual User Interface],
my ui freezes 5s after submitting query ,then suddenly update with new messages.

[willmcgugan]

We can't help without seeing your code.

But if I were to make the change to mother.py you described, I would expect it to freeze the UI. The @work decorator won't automatically make something run "in the background". Coroutines can only switch to doing something else when they encounter an await statement. If there is no await statement, then the UI will freeze until the method returns.

If you want more help, then we will need an MRE. I'm afraid its too much to expect us to debug your app.

[femto]

After hours of unfruitful debug, and make many tries not able to produce MRE. For mock agent,
the ui is fine.
my project's entrypoint is here https://github.com/femto/minion-code/blob/main/examples/repl_tui.py,
I tried with gpt-4o, that's more responsive now, originally I'm always using bedrock's sonnet
to write my agent.
seemed relevant, it's because the official Boto3 SDK for Bedrock (boto3.client('bedrock-runtime') or 'bedrock') is synchronous only.
(see https://stackoverflow.com/questions/78348036/how-to-call-aws-bedrock-asynchronously).

I think the reason I see a ui halt is probably update ui then call bedrock immediately, and ui won't update.
There's only small chances after ui update attribute ui gets a chance to refresh before doing bedrock work?
my agent entrypoint is already async, I always call await agent.run_async(...) to do some work, and has
a lot of async/await (you can think of agent --> brain --> ActionNode --> llm, all the way down's method
is async and needs await. So it's final layer's one step of bedrock sync causes ui halt.