Assist on WearOS closes without actioning request

[craigmate]

Home Assistant Android app version(s):
2025.11.1
Android version(s):
Android 15
WearOS 5

Device model(s):
Samsung S23 PLus:
Samsung Galaxy watch6

Home Assistant version:
2025.10.4
Last working Home Assistant release (if known):
Last Stable Update
Description of problem, include YAML if issue is related to notifications:

When I try and run assist from my WearOS app, it opens, then after 5 seconds closes, before performing any actions

Here is a link to a video of me trying

https://photos.app.goo.gl/YbqtTe9epSzFpP7G8

Companion App Logs:

Screenshot or video of problem:

Additional information:

[jpelgrom]

I'm not able to reproduce this on Wear OS with 2025.11.2 (beta). Would you be willing to join the beta to see if you still have this issue with 2025.11.2?

Can you also check the Assist logs on your server? That might tell us what the server receives, if anything. Go to Settings > Voice assistants > click on the three dots next your assistant > Debug, and look at when you tried using the watch. Which steps does it show (Speech-to-text / Natural language processing / Text-to-speech / more?)? Does it contain any errors?

[craigmate]

HI,
Thanks for getting back to me, I did a couple of things with the app, like toggling the assist on and off button, and it seems to be working a bit at the moment, a bit strange, will monitor it for a few days, I generally only use it to open and close my garage when I am in my car. I did a quick test to turn on my lights and it worked fine...

[ruostee]

What did you do? I have the same problem with galaxy watch 8

[zareami10]

Same issue on Galaxy S series/Pixel watch, cannot use Assist after recent updates.
Removing cache/app date or updating to Beta does not solve the issue.

[craigmate]

HI .. So its a bit strange, if I open it, and hold it until it shows the options to select the drop down for the assist pipeline, it sometimes stays open and executes the command. However it sometimes takes 3 attempts before it works. I am glad I am not the only one having this issue, I haven't setup the beta or anything, since I thought it started working.

[ruostee]

Doesn't work at all. As soon as I see it connecting to my assistant it crashes. It's so quick that I can't even select which assistant I want to use.

[MacrosorcH]

Same here with Pixel Watch 2: HA Assist crashes right after starting, right in the moment it connects to Home Assistant. I'm on latest version 2025.11.3.

[dshokouhi]

I can reproduce on my pixel watch 3, closes before I can even talk

2025-11-18 13:22:19.151 12582-12582 AndroidRuntime          pid-12582                            E  FATAL EXCEPTION: main (Ask Gemini)
                                                                                                    Process: io.homeassistant.companion.android, PID: 12582
                                                                                                    java.util.ConcurrentModificationException
                                                                                                    	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
                                                                                                    	at java.util.ArrayList$Itr.next(ArrayList.java:1064)
                                                                                                    	at io.homeassistant.companion.android.common.assist.AssistViewModelBase$runAssistPipelineInternal$1$1$1.invokeSuspend(AssistViewModelBase.kt:227)
                                                                                                    	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:34)
                                                                                                    	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
                                                                                                    	at android.os.Handler.handleCallback(Handler.java:1041)
                                                                                                    	at android.os.Handler.dispatchMessage(Handler.java:103)
                                                                                                    	at android.os.Looper.dispatchMessage(Looper.java:315)
                                                                                                    	at android.os.Looper.loopOnce(Looper.java:251)
                                                                                                    	at android.os.Looper.loop(Looper.java:349)
                                                                                                    	at android.app.ActivityThread.main(ActivityThread.java:9041)
                                                                                                    	at java.lang.reflect.Method.invoke(Native Method)
                                                                                                    	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:593)
                                                                                                    	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:929)
                                                                                                    	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@fa6c6da, Dispatchers.Main.immediate]

[koenieee]

Same issue here

[Georgi81]

Same here :(

[TimoPtr]

@jpelgrom I've looked at this a little and I see that we are using the recorderQueue to store records but this queue can be update while receiving the STT_START event which lead to this exception.

The logic seems quite complex and not straightforward to follow. I'm kinda afraid of all these coroutines touching this object. Even if it uses viewModelScope it makes network calls so the coroutine is suspended and another one can add data into the queue.

I can make something dumb like just make a copy of the recorder before sending the data in STT_START and clear the queue right away but then the order of the records could be mess up (I think)....

I would need more details to dig deeper on this issue or if you can have a look 🙏🏻.

[jpelgrom]

@jpelgrom I've looked at this a little and I see that we are using the recorderQueue to store records but this queue can be update while receiving the STT_START event which lead to this exception.

I can see that potentially happening, but 1) this logic hasn't changed in a while so I'm not sure why this issue appears to have started happening after the last published update and 2) that is kind of the goal, having a place to keep recorded voice data while we're not yet ready to send it/haven't sent previous bytes.

(This queue was mainly added to have a faster start of Assist with it recording proactively, so you can push the button and talk while the app sets up network, pipelines, etc. Most noticeably faster on Wear OS. See: #3755 for more background and a demo.)

I can make something dumb like just make a copy of the recorder before sending the data in STT_START and clear the queue right away but then the order of the records could be mess up (I think)....

Then you potentially lose recorded bytes between the app receiving STT_START and it finishing sending the bytes, and/or you potentially send bytes out of order (for example: if you're sending 100x and a new one comes in while sending 63, you get 62 > 63 > 101 > 64).

[TimoPtr]

@jpelgrom I've looked at this a little and I see that we are using the recorderQueue to store records but this queue can be update while receiving the STT_START event which lead to this exception.

I can see that potentially happening, but 1) this logic hasn't changed in a while so I'm not sure why this issue appears to have started happening after the last published update and 2) that is kind of the goal, having a place to keep recorded voice data while we're not yet ready to send it/haven't sent previous bytes.

Potentially my changes on the background threading and removing some 'runblocking'.

(This queue was mainly added to have a faster start of Assist with it recording proactively, so you can push the button and talk while the app sets up network, pipelines, etc. Most noticeably faster on Wear OS. See: #3755 for more background and a demo.)

I can make something dumb like just make a copy of the recorder before sending the data in STT_START and clear the queue right away but then the order of the records could be mess up (I think)....

Then you potentially lose recorded bytes between the app receiving STT_START and it finishing sending the bytes, and/or you potentially send bytes out of order (for example: if you're sending 100x and a new one comes in while sending 63, you get 62 > 63 > 101 > 64).

Yep ... That's what I had in mind too .. We need to think about how to properly handle synchronization here. We could add a mutex to protect the queue.