remap pty ids during session restore after server restart

[jossephus]

session switching might be my most used prise feature. I sometimes go back to a session that i was working on in previous weeks and When opening old sessions, I kept getting stuck at 'Waiting for terminal...' screen. This is my investigation into this issue.

The issue was happening when spawn gets a pty_validity mismatch. Incases when the server was restarted, fresh ptys are spawned but get new ids. The session JSON still references old IDs, causing ptyLookup to fail and deserialize_node to return nil, resulting in empty tabs and "Waiting for terminal..." error.

It can be reproduced using the following steps

Reproduction

1. start a session: prise -s test-session
2. press d to detach the session
3. restart prise server: 'brew services restart prise' or 'launchctl unload ~/Library/LaunchAgents/sh.prise.server.plist'
4. reattach - 'prise session attach test-session'

Fix: Track old→new PTY ID mapping when spawning fresh PTYs, and use this mapping in ptyLookup during session restore.

checkout the conversation i had with amp to grasp the context: https://ampcode.com/threads/T-019bb38e-0061-73fa-a780-f3228258cb7f

[austinm911]

I've also frequently run into this Waiting for terminal bug. Below also ends up occurring when the Waiting bug seems to occur. You can see that I have a session home but can't attach to it. Not sure if it's related to what you're exploring but figured I'd drop this here.

[jossephus]

I've also frequently run into this Waiting for terminal bug. Below also ends up occurring when the Waiting bug seems to occur. You can see that I have a session home but can't attach to it. Not sure if it's related to what you're exploring but figured I'd drop this here.

yes it might be related to it.

can you share the session information for home from ~/.local/state/prise/sessions/home.json please?

[austinm911]

@jossephus sure!

{"pty_validity":1768611357745,
  "next_tab_id": 11,
  "active_tab": 0,
  "tabs": {},
  "focused_id": 25,
  "next_split_id": 6,
  "floating_settings": {
    "height": 30,
    "width": 100
  }
}

[jossephus]

@austinm911 the issue you are facing here is not related to this PR. as u have noted in #89 it looks like the issue is having 'tabs: {}' instead of 'tabs: []'. i will create a PR that handles this gracefully. but before that are you able to reproduce why 'tabs: {}' happened in the first place. I am not able to reproduce it from my side.

[rockorager]

Thanks!

[austinm911]

@jossephus I am not sure quite how it gets reproduced. I'll try to keep an eye out when/if it happens again. What I was usually doing was using ghostty with pi coding agent. I would have a handful of tabs in a session with them split. Some tabs would have running dev servers and some would have pi running.

[austinm911]

@jossephus ok seem to have hit this issue again. I believe it occurred again after a subagent was spawned using pi coding agent https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent/examples/extensions/subagent. But, what i do notice is all prise session are broken, not just the point highlighted below.

Not 100% sure this is really the repro as i do use subagents quite a bit with pi so when trying this another subagent it did not break. Anyways just figured I let you know. I did have 3 sessions each with a few tabs open.

{"pty_validity":1768936044680,
  "next_tab_id": 18,
  "active_tab": 0,
  "next_split_id": 19,
  "tabs": {},
  "floating_settings": {
    "height": 30,
    "width": 100
  },
  "focused_id": 24
}