-
Notifications
You must be signed in to change notification settings - Fork 35
fix(api): mcp error with remote server #95
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
Conversation
|
I did some tests on this and according to the opencode docs custom command can take arguments. ---
description: Say hello to bob
agent: plan
model: github-copilot/gpt-4.1
---
Say hello to bob $ARGUMENTS and ask how he is doing today.
This dummy command used to let me add arguments after completion What it did was inserting the text Hope it helps |
|
Ah, that's very helpful. I'll take a look! |
Add autocomplete to `:Opencode command` and add user commands to slash commands list.
Custom commands don't take arguments
1152b9e to
0373797
Compare
I had broken it because I didn't think it was supported. But it was :)
We were swallowing some errors (e.g. vim.filetype.match). None of them seemed important but it's possible there will be errors in the future that we need to surface. Added util.pcall_trace that will return a full stacktrace in result, rather than just the error.
This can actually trigger a race condition between renderer.render_full_session and opencode delivering responses to the prompt.
Renderer already subscribes to state.active_session
|
@sudo-tee I fixed arguments for users commands so now it works for both In my testing, I did uncover two race conditions. I've already fixed the first (we were triggering a full session load when sending a user command but we don't need to do that so I just removed the full re-render). The second can still happen via the following sequence:
The issue is that opencode.nvim/lua/opencode/api.lua Lines 272 to 281 in 1941a34
Because opencode.nvim/lua/opencode/ui/renderer.lua Lines 117 to 123 in 1941a34
I think that means it's possible we can start processing events before we've reloaded the session, which means I think would lose events if the sequence went:
For 1, we need to force the session load to be synchronous. My proposal is to change ---Force a full rerender of the output buffer. Should be done synchronously if
---called before submitting input or doing something that might generate events
---from opencode
---@param synchronous boolean If true, waits until session is full rendered
function M.render_output(synchronous)
local ret = renderer.render_full_session()
if ret and synchronous then
ret:wait()
end
endAnd then I think we only need to set How's all of that sound? |
|
Great catch. I think the proposed solution is good enough. |
As discussed in sudo-tee#95, there's a race condition if a display_route was used and now we're submitting an input prompt. To fix, we wait for the session to fully render before submitting the input
|
Ok, I think this should be all set now |
As discussed in #95, there's a race condition if a display_route was used and now we're submitting an input prompt. To fix, we wait for the session to fully render before submitting the input
|
Great job on this :) Thanks a lot |
Fixes #93