zellij icon indicating copy to clipboard operation
zellij copied to clipboard

Inconsistent Session Serialization / Resurrection

Open Aequitosh opened this issue 7 months ago • 5 comments
trafficstars

As the title says, zellij is sometimes inconsistent when it comes to session serialization / resurrection.

Version: 0.42.1, installed via cargo install zellij

To describe my specific case:

  • Occasionally tabs will be missing or not be restored to their original state.
    • For example, I usually have a couple Neovim instances open, because auto-session + zellij allows me to instantly return to whatever I was working on (zellij is awesome in that regard btw, absolutely love it).
    • Sometimes those tabs will just take me to my home directory instead, while some other tabs do take me back into Neovim or my mail client.
  • Panes seem to be more consistent in this regard, except the first pane in a tab.
    • The first pane will often also just take me to my home directory, while the second pane (and onwards) will be restored correctly.
    • To give a more concrete example, when working with git, I'll often have two panes (left and right) in which I'll run git commands. Upon resurrection, the left pane will often just take me to my home dir, while the right pane will drop me into the dir of the repository I was working in (as expected).
  • The directory in which my shell runs is inconsistent.
    • In my default session, I'm always put into my home dir whenever I open a new tab.
    • In a different, brand new session, when I go to ~/Documents and open a new tab, I am also put into ~/Documents. When I now cd ~/Documents/Notes and open a new tab, I am now put into ~/Documents/Notes.
    • I have made a new session named debug in order to reproduce this---in this session, whenever I open a new tab, I will be dropped into ~/Documents for some reason, no matter what directory I am in currently. That was the first directory I ever cded into in this session, so perhaps that's why..?
    • This behaviour (in the session named debug) only started to occur after the session was killed for the first time.
    • Panes seem to not be affected by this and will always drop me into the directory of the pane was previously in focus.
  • Certain commands are not executed in the same manner as they were before resurrecting the session.
    • For example, when I run git log in some repository, detach, kill the session (after it was serialized), re-attach to the session again, less will complain that it hasn't received any input (since I use less as my pager for git).
    • git branch will also have a different output format upon resurrection. I have the following in my ~/.gitconfig:
      [column]
              ui = auto
      
      This causes my branches to be displayed as columns instead of one huge list. However, when resurrecting a session, this isn't respected; git branch shows a list of branches instead.

The last point regarding commands isn't that much of a big deal honestly, but it's something I have noticed on occasion nevertheless. I don't actually keep my branches open like that, but proved to be a good test case.

This is all quite hard to reliably reproduce, so I will try my best to provide as many additional details as possible whenever I'm able to. I hope this helps in some way already. If there's anything specific you'd like me to test / do / try out, please let me know!

Aequitosh avatar Apr 10 '25 12:04 Aequitosh

Just to make sure we're not stumbling on this - you said you installed with cargo install zellij did you use the --locked flag? If not this is the first thing I'd try. Arbitrary (transient-)dependency upgrades can do odd things and it makes sense that these will happen when interacting with system libraries.

Otherwise, sessions are serialized into a Human readable layout. You can also do this on demand to STDOUT with zellij action dump-layout. This is the same process used when serializing sessions, so it might help you troubleshoot this a bit further to narrow down any issues so we can take a closer look.

imsnif avatar Apr 10 '25 13:04 imsnif

I did not! I just reinstalled it using cargo install --force --locked zellij. Will see if the behaviour changes. I also ran rm -rf ~/.cache/zellij, essentially starting from scratch, just to rule out any issues in that regard. I didn't really have any complex layouts or stuff like that saved, so I'm fine with starting from scratch. I'll report back once I find out more---or if the issue vanishes.

Aequitosh avatar Apr 11 '25 09:04 Aequitosh

So I can confirm this happens to me when a size=1 pane is split into children panes with fractional sizes:

layout {
    pane size=1 split_direction="vertical" {
        pane size="50%" borderless=true {
            plugin location="tab-bar"
        }
        pane size="50%" borderless=true {
            plugin location="status-bar"
        }
    }
}

Setting the parent pane to size=2 or children to fixed non percentage size seems to produce a valid output

mkatychev avatar Apr 21 '25 18:04 mkatychev

Thank you!! I'm making a note of this and will take a look before next release.

imsnif avatar Apr 22 '25 06:04 imsnif

@imsnif I've written a test case that reproduces the issue: https://github.com/zellij-org/zellij/blob/56963ab40bf0e57305cb3a415094d2e88f110e86/zellij-utils/src/session_serialization.rs#L1144-L1148

mkatychev avatar May 05 '25 21:05 mkatychev

I issued a fix in https://github.com/zellij-org/zellij/pull/4442 for the cases described by @mkatychev - thanks for the excellent reproductions! Would you like to make a PR to add your test (and also update the expect blocks to match) so that you get credit for this?

As for @Aequitosh - I guess the --locked fixed these issues for you? I have a feeling if not we're dealing with a different problem or set of problems, but I would need a reproduction (something on the same resolution provided by @mkatychev ). Happy to make suggestions for troubleshooting this in any case.

imsnif avatar Sep 25 '25 09:09 imsnif

I can do that

mkatychev avatar Sep 25 '25 13:09 mkatychev

As for @Aequitosh - I guess the --locked fixed these issues for you? I have a feeling if not we're dealing with a different problem or set of problems, but I would need a reproduction (something on the same resolution provided by @mkatychev ). Happy to make suggestions for troubleshooting this in any case.

Sorry, this wasn't on my radar for a while! The issue still persists for me, but I've kind of just learnt to deal with it in the meantime. I'll see if I can give #4442 a shot soon, though.

Edit: Built Zellij on #4442 and will see if that fixes (some of) my issues. Thanks for all the efforts, much appreciated!

Aequitosh avatar Oct 13 '25 11:10 Aequitosh

@imsnif I've now done some minor testing, or rather, I've continued to use Zellij as I always do based on PR #4442. I only had to create the sessions from scratch again (it uses ~/.cache/zellij/0.44.0 now instead of ~/.cache/zellij/0.42.2, which is expected due to the version being newer); everything else worked so far.

In particular, these points of mine seem to have been fixed now:

  • Occasionally tabs will be missing or not be restored to their original state.
  • Panes seem to be more consistent in this regard, except the first pane in a tab.
  • The directory in which my shell runs is inconsistent.

I'll continue to use Zellij as I always do and will also regularly serialize my sessions manually to keep track of how they evolve over time.

Regarding my last point:

Certain commands are not executed in the same manner as they were before resurrecting the session.

This has honestly been very rare for me and tbh it's not been a big deal for me so far. I can't really say whether this issue still occurs or has been fixed, as I haven't encountered it for a while. That being said, that might also be because half of the tabs / panes of my sessions would previously just get lost, so I'll keep an eye on it nevertheless.

I'll keep you posted—for now it's been stable and has survived multiple session kills and restores.

Thanks a lot for the fix, I really appreciate the hard work! 🙏

Aequitosh avatar Oct 17 '25 11:10 Aequitosh