Sign up
View stargazers13Sign up

[Bug]: `t3 auth session list` reports connected: false for every session, live ones included (CLI has its own in-memory state)#21236

opened5d agobyHhopchouinard

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

  • apps/server

Steps to reproduce

  1. Run the server (for example as a systemd user service) and connect a client: desktop over SSH, or a paired phone.
  2. On the same host, run t3 auth session list --json.

Expected behavior

connected is true for the sessions that have a live WebSocket, as in the app's Settings → Connections (/api/auth/clients).

Actual behavior

connected is false for every session, including the ones carrying live connections at that moment (checked against ss and the server's markConnected/markDisconnected trace spans).

The cause, from the source: connection state lives only in the server process's memory (SessionStore connectedSessionsRef). The CLI builds its own EnvironmentAuth.layerRuntime (apps/server/src/cli/auth.ts:42), so its map is always empty. For the same reason, t3 auth session revoke only updates the database. As far as I can tell, it never reaches the running server's invalidation channel, so a live socket on a revoked session stays up until it drops.

This matters when cleaning up the session pile-ups of #20288. The new docs (#20445) point to the CLI for revoking unused sessions, but its connected column can't tell an unused session from a live one. The only reliable signal from the CLI is a null lastConnectedAt ("never connected").

Impact

Minor bug or occasional failure

Version or commit

Server 0.1.0; apps/server/src/cli/auth.ts on main (2026-10-18) still uses layerRuntime.

Environment

Linux, server run as a systemd user service; the CLI is run as the same user on the same host.

Logs or stack traces

text
1t3 auth session list --json -> 442 sessions, all "connected": false
2ss -tn state established | grep 127.0.0.1:3773 -> 2 live client connections at the same moment

Workaround

None from the CLI. Use Settings → Connections in the app, or /api/auth/clients with a session that has the right scope.

JJulius Marminge5d ago

Note

Grok responding on behalf of Julius.

Confirmed on main, keeping this open as a bug. The CLI auth commands in apps/server/src/cli/auth.ts build their own EnvironmentAuth.layerRuntime, and live connection state is only tracked in memory in SessionStore (connectedSessionsRef) inside the server process. So t3 auth session list always reports connected: false, even for sessions with an open socket.

Until this is addressed, the connected column from the CLI is not a reliable way to tell idle sessions from live ones. A null lastConnectedAt does reliably mean the session never connected, and the app's connections view reads the running server's state.

The second part of your report, about revoke from the CLI, is being reviewed separately.

JJulius Marminge2d ago

Reproduced on Linux at main b5a226e49c, using an isolated worktree dev server and copied development data.

Issued a temporary CLI session, obtained a WebSocket ticket, opened /ws?orchestrationProtocol=2, and ran node apps/server/src/bin.ts auth session list --json --base-dir .t3 while that socket remained open. For the same session:

text
1WebSocket.readyState: 1 (OPEN)
2GET /api/auth/clients: connected: true
3CLI auth session list: connected: false
4Both returned lastConnectedAt: 2026-10-21T23:59:46.813Z

No duplicate found in the open-issue scan covering the last 90 days. This confirms the connection-status bug; the separately scoped revocation report was not tested. No fix was written: changing the CLI authentication runtime/server state path requires maintainer handling under this triage flow's authentication hard stop.

JJulius Marminge2d ago

Reproduced on Linux at main 8acbefefc5: with the same WebSocket session open, the server returned connected=true and the CLI returned false. Fixed in #23277. The focused regression test and runtime transcript now agree with the running server; the separate revocation report is outside this change.