-
Notifications
You must be signed in to change notification settings - Fork 52
fix: restore model from session messages on load #346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: refactor/renderer-components
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -93,24 +93,6 @@ local function fetch_session() | |||||||||||
| return require('opencode.session').get_messages(session) | ||||||||||||
| end | ||||||||||||
|
|
||||||||||||
| ---Set the current model/mode from the most recent assistant message | ||||||||||||
| local function set_model_and_mode_from_messages() | ||||||||||||
| if not state.messages then | ||||||||||||
| return | ||||||||||||
| end | ||||||||||||
| for i = #state.messages, 1, -1 do | ||||||||||||
| local message = state.messages[i] | ||||||||||||
| if message and message.info and message.info.modelID and message.info.providerID then | ||||||||||||
| state.model.set_model(message.info.providerID .. '/' .. message.info.modelID) | ||||||||||||
| if message.info.mode then | ||||||||||||
| state.model.set_mode(message.info.mode) | ||||||||||||
| end | ||||||||||||
| return | ||||||||||||
| end | ||||||||||||
| end | ||||||||||||
| require('opencode.core').initialize_current_model() | ||||||||||||
| end | ||||||||||||
|
|
||||||||||||
| ---Render all messages and parts from session_data into the output buffer | ||||||||||||
| ---Called after a full session fetch or when revert state changes | ||||||||||||
| ---@param session_data OpencodeMessage[] | ||||||||||||
|
|
@@ -122,7 +104,6 @@ function M._render_full_session_data(session_data) | |||||||||||
| end | ||||||||||||
|
|
||||||||||||
| local revert_index = nil | ||||||||||||
| local set_mode_from_messages = not state.current_model | ||||||||||||
|
|
||||||||||||
| flush.begin_bulk_mode() | ||||||||||||
|
|
||||||||||||
|
|
@@ -163,9 +144,7 @@ function M._render_full_session_data(session_data) | |||||||||||
| flush.flush() | ||||||||||||
| flush.end_bulk_mode() | ||||||||||||
|
|
||||||||||||
| if set_mode_from_messages then | ||||||||||||
| set_model_and_mode_from_messages() | ||||||||||||
| end | ||||||||||||
| require('opencode.core').initialize_current_model() | ||||||||||||
|
||||||||||||
| require('opencode.core').initialize_current_model() | |
| local core = require('opencode.core') | |
| if core and core.initialize_current_model then | |
| core.initialize_current_model({ restore_from_rendered_session_messages = true }) | |
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
initialize_current_model()now prioritizesstate.messageseven whenstate.current_modelis already set. Since this function is called in non-session-load paths (e.g.core.send_message()setsopts.model = opts.model or M.initialize_current_model():await()), this will override a user-selected model (viaconfigure_provider()/state.model.set_model) back to whatever model was used in the most recent message, effectively making model switching not stick until after a new assistant message is produced.Suggested fix: don’t apply the “restore from messages” logic when
state.current_modelis already set, or gate it behind an explicit option (e.g.initialize_current_model({ prefer_messages = true })) so only the session-load renderer path forces restoration from message history.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The edge case you described only occurs when a user switches models in TUI without sending a message. If they switch and send, the message history is updated with the new model, and nvim will correctly use it on the next send.
Given that users typically switch models to use them immediately, this edge case is rare. The current fix prioritizes simplicity over handling this specific scenario with an additional API option.