fix: create new session when goose fails to find existing session

[p5]

Summary

Do not panic on startup when no sessions exist.
This fixes an issue where the user’s first session with Goose fails with a panic before it even begins. This is because the previous code unconditionally unwrapped the result of SessionManager::get_session, causing a panic when no session data was found or when session loading failed for any reason.

The new implementation handles this case gracefully by returning an empty, unvalidated Conversation when a session cannot be loaded, allowing Goose to start cleanly even when no prior sessions exist.

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

Testing

This has been tested manually by configuring Goose with GitHub Copilot and running goose in a clean environment. Previously this caused an error. Now it correctly starts a new session.

Related Issues

Relates to #5197
Discussion: LINK (if any)

Screenshots/Demos (for UX changes)

Before:

After:

Email:

[DOsinga]

thanks for diving on this. this would probably help, but I would love to understand better why this is happening in the first place? if you just have goose session, why does it come up with a session that does not exist?

[DOsinga]

can you remove the comment here and print something sternly here? like what the session_id was that we thought we were loading? I would like to know how we get us a session_id that doesn't exist; the only way to get in that situation should be that the user entered an invalid one

[p5]

This occurs when a new user attempts to start Goose in the first place. The user has no existing sessions

Will action your other comment now, and spend a few minutes diving deeper into the root cause.

Edit:
Ah, I see what you mean - we shouldn't be entering into that if condition when session_id isn't provided. And on first use, it shouldn't be present.

[DOsinga]

yeah we have:

let messages = if let Some(session_id) = &session_id {

so session_id must be set. so it must come from somewhere. what is the value?

[DOsinga]

thanks. interesting.

so 20251016_1 is the session id of a new session that the session manager made for us, not some random string. which is what you would expect, you start and we create a new session and then try to load that. why did it not get created is then the question? if you could give it a bit more time looking into?

[p5]

On starting a new session with (goose), the following are set:

vscode ➜ /workspaces/goose (fix-failing-initial-session) $ ./target/debug/goose 
# In session/builder.rs
SESSION CONFIG NO_SESSION: false
SESSION CONFIG RESUME: false
SESSION CONFIG SESSION_ID: None

# In session/mod.rs
Session ID: Some("20251016_1")

So session_id is being generated here if there is no session. The only time when there is no session_id in the CliSession::new(...) is when no_session is set.

So now the question is: Why does SessionManager::get_session(session_id, true).await panic? Because there's no conversations within that newly-generated session? Investigating

[DOsinga]

I think the problem might be that we try to load the session where it crashes in a different context. so the session has been created but might not have made it to the db. since we read it from the other thread, it might not exist in that context yet and we die.

[p5]

I think you're right. Though I'm not quite sure what the desired fix here would be.
Perhaps an optional conversation input to the CliSession::new(..) function, which would be Some(<empty-conversation>) when the session is newly-generated? That way, you don't need to read from the DB.

[jamadeo]

@p5 we think this may fix the issue: #5202 if you're able to give that a shot on your system. We're working on more testing on our end