chore: improve timeout for entering password when running goose ui from source

[alexhancock]

Right now we only have 20sec to enter our password when we run goose ui locally and goosed starts and needs the keychain password. I often miss it and goose turns into a brick, and needs to be relaunched. This will give 2min instead of 20sec.

[DOsinga]

this seems fine, but I wonder in general why we need this at all? it always reeks like either LLM generated defensive code that isn't really useful or is about something that happened at one point (goosed would not start) but not anymore

goosed exiting because of something is much more likely than goosed not starting. and we don't handle the password thing well anyway you say.

[alexhancock]

Good callout. I can look deeper and see if we even still need it.

[jamadeo]

Is this just in dev mode? I thought I actually just ran into this with a built app when I had it configured for a provider that used oauth.

Another fix would be for /status to still return 200 even if we're waiting on a keyring or oauth or something. I'm actually not sure why it wouldn't. Do we not start serving until an agent is created or something?

[jamadeo]

to put it another way, ideally we don't time out at all if we're waiting for the user to enter something. Maybe for oauth we need to because we don't know if they've closed the browser window, but for the password entry, timing out at all doesn't make much sense

[DOsinga]

I think this is the password you enter to give goose access to your keychain and the timeout is how long we give goosed to become responsive

[alexhancock]

Good questions @jamadeo and I agree. I think it comes up more in development for two reasons I think:

1. We wait a bit for rust to compile etc, so often when running just run-ui we multitask and forget to come back right when the app is available
2. We need to enter our password every launch, whereas with built apps we only do it once for that build

But totally possible this bug exists in the built version of the app, which is actually quite rough...

I'll merge this to at least make it better for the moment and look closer at whether checkServerStatus can be improved or eliminated.

[jamadeo]

I think this is the password you enter to give goose access to your keychain and the timeout is how long we give goosed to become responsive

right, yeah, but the combination of those effectively means you have X seconds to enter your password or the app dies, if I'm understanding this issue

the app should die if goosed doesn't start up, but it should not die if it's just waiting for user input

[alexhancock]

the app should die if goosed doesn't start up, but it should not die if it's just waiting for user input

yes agree. I've made it better in this PR as we now have a two minute timebomb instead of a 20s timebomb, but haven't fixed it. I'm unclear if it happens the same way in a built version of goose though. Will test now.

[jamadeo]

huh, actually I'm also unable to replicate. if I start a newly built goosed, I get a "200 ok" from /status before it asks for keyring access

[DOsinga]

but the user input request comes from goosed, so the electron app has no way to see if it is that. on the other hand, why does the /status handler not succeed? when I tested it, /status returns with the keychain box open, so when exactly do you see this error?

[alexhancock]

on main prior to this commit if you just run-ui and wait longer than 20s to enter the password required for keychain access an error appears, Server failed to respond after 20s shows in the terminal logs, and goose is bricked

[DOsinga]

I don't see this - running from the 1.12.0 branch

[alexhancock]

Attaching what I experience on main with a hard reset to 398cd1dfad8c73847f2d53f73cb1a8ef88312050 which is the commit from right before I merged this

goose-20s-timeout.mov

[jamadeo]

yeah, something is off here, I can reproduce it when I run just run-ui, and the server prints as far as INFO goose::scheduler_factory: Creating legacy scheduler. But if I then run ./target/release/goosed agent directly, it begins serving (INFO goosed::commands::agent: listening on 127.0.0.1:3000) and does not ask for a password, and does respond to /status

[jamadeo]

Ok, this is because as of #4684 we configure a provider using GOOSE_DEFAULT_PROVIDER / GOOSE_DEFAULT_MODEL before starting the server. This could block on oauth or password entry