Tracking issue for server stability (old 1)

[raphCode]

Here I collect open issues related to zellij server stability, meaning problems that may cause sessions to crash or become otherwise unuseable. Currently, I limit this list to issues where active work can get lost, e.g. a new session crashing directly at startup is out of scope.

Server crashes

• always crashes on resize #1551
• Strider plugin panics when double clicking in empty directory #1423
• Thread 'screen' panicked when attempting to rename a floating panel #1323
• Zellij server crashes when killing X session #1040
• interrupting cat (CTRL-C) panics stdin_handler_thread #1340
• Crash when catting random bytes #1346
• Crash and burn while compiling zellij, and running rust analyzer #1108
• Zellij Automatically Exits when SSH is disconnected #1029
• Error: thread 'screen' panicked at 'called Option::unwrap() on a None value': zellij-server/src/screen.rs:226 #805
• Crash when exiting shell on single CPU systems #882
• Zellij crashes when clicking with mouse in pane #816
• Zellig crashes when pasting long line continued shell commands #528
• Not sure what did I do, but zellij crashed #929
• Panic on Tab open: PreopenedDirectoryNotFound #1217
• hang/crash when closing last pane in tab with hidden floating pane #1241
• Zellij server stability discussion #1050
  crash on new tab open, most likely resolved after clearing plugin cache
  To avoid this problem, use cargo make run instead of cargo run for test builds.
• Server pty_thread panicked at failure to spawn for new pane #979

Inaccessible session / corruption

• zellij session freezes after some time #1209

I suggest to keep comments to their respective issues instead of here, to keep this tracking issue "clean" of crash details.

Feel free to ping me in other / new issues if I should update this list.

[jaeheonji]

Thank you so much for your hard work! this is really cool 👍

[raphCode]

Ideally, we can fix panics / crashes before they occur to users.
For this, we should make most / all server code that interacts with syscalls and the wasm plugin system fail gracefully instead of panicing.
The rest of the possible panics are probably internal logic bugs anyway.

I am not sure on how to approach that - should I spam a bunch of new issues for all the potentially offending code locations I can find?

[jaeheonji]

First of all, I personally think that the key to this problem is the unexpected unwrap code.

The intentional panic code is a necessary part (currently about 10-15 lines of the entire code) and I'm working on an error-reporting system for it.

However, verifying all unwrap code is very difficult. "ideally" we should fix the error before the user sees it, but in the end, it's natural to get feedback from users and fix it.

So I think the purpose of this issue is to gather stability-related issues from new issues.
And we'll just have to add the problems we find naturally in developing.

should I spam a bunch of new issues for all the potentially offending code locations I can find?

I think it would be fine to organize small-scale code into markdown tables with permalink. and It would be nice to create a new issue and link to it only for those that need discussion and detail.

[a-kenji]

@raphCode,
Do you mind recreating the issue?
It is now a bit cluttered and we can still link back to this one.

[raphCode]

The new issue is #1568