Open lostl1ght opened 1 month ago
Thanks for reporting, I'll look into this more ASAP :)
vim.rpcrequest
also does the trick since it is a blocking call:
diff --git a/lua/flatten/core.lua b/lua/flatten/core.lua
index 0d1622f..5645f62 100644
--- a/lua/flatten/core.lua
+++ b/lua/flatten/core.lua
@@ -2,7 +2,7 @@ local M = {}
function M.unblock_guest(guest_pipe)
local response_sock = vim.fn.sockconnect("pipe", guest_pipe, { rpc = true })
- vim.rpcnotify(
+ pcall(vim.rpcrequest,
response_sock,
"nvim_exec_lua",
---@diagnostic disable-next-line: param-type-mismatch
But it has to be pcall
ed, otherwise I get an error:
(mini.bufremove) vim/_editor.lua:0: nvim_exec2()..BufUnload Autocommands for "<buffer=8>": Vim(append):Error executing lua callback: Invalid channel: 5
stack traceback:
[C]: in function 'rpcrequest'
/home/desc/plugins/flatten.nvim/lua/flatten/core.lua:5: in function 'unblock_guest'
/home/desc/plugins/flatten.nvim/lua/flatten/core.lua:22: in function </home/desc/plugins/flatten.nvim/lua/flatten/core.lua:20>
[C]: in function 'nvim_exec2'
vim/_editor.lua: in function <vim/_editor.lua:0>
[C]: in function 'pcall'
...site/pack/deps/opt/mini.bufremove/lua/mini/bufremove.lua:234: in function 'delete'
/home/desc/.config/nvim/lua/plugin/lazygit.lua:17: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
There are some complexities with using rpcrequest
here - I believe I used to do it that way. If the socket has been closed from the other side, this can also cause a hang. As far as pcall
goes, it'd be better to check if the channel is valid beforehand, since that seems to be the cause of the error. You can use nvim_get_chan_info
for that.
I can't put my finger around how the channel becomes invalid. The only two places where channel gets closed is in the autocmd callback and before the sleep loop. nvim_get_chan_info
doesn't seem to provide useful info:
{
client = {
[true] = 6
},
id = 5,
mode = "rpc",
stream = "socket"
}
Hello!
Describe the bug Blocked shell sometimes does not unblock. I cannot provide steps to reproduce because it happens sporadically. The quickest way I'm able to reproduce is committing with lazygit inside toggleterm and setting up an auto command to delete the buffer after writing. It happens 1-5 times out of 10.
Expected behavior Shell to unblock
Desktop (please complete the following information):
Additional context After many trials and errors: scheduling API functions in callbacks, deferring them with long timeouts, with short timeouts, I may have an idea of what's happening:
My idea is that the channel gets closed before guest fully receives the command to close. That's why I tried to give the guest a good second to get the command. With this patch it looks that the freezing is not happening. I'm going to test drive this patch for a few days to see if that's indeed the case.
Also, I'm also deferring closing the channel in
maybe_block()
just for good measure and I've increased sleep time since (I think) there's not point in wasting CPU time waking up and going to sleep every second.Please, provide any thoughts and ideas on this issue.