Repository navigation
[FEATURE]: include slug on SessionInfo (v2), so plugins can name sessions they did not see created #53779
Description
Activity
Thanks for the detailed request! You're asking for
slugto be added to v2'sSessionInfo, the object returned bysession.get/session.listandGET /api/session. Plugins could then look up the slug of any session, including ones created before the plugin or background service started.The code matches what you describe. The slug is stored on every session, but the only v2 event that includes it is
session.created, and the v2Session.Infoschema doesn't have the field. The v1 session object did. Plugins also have no way to read back an earlier session's slug, so keeping your own record of slugs, as you do now, is the only option. That's why a plugin can't fill this gap on its own.The maintainers will consider it. A related earlier change is #48059 (closed), which exposed session
metadatain the V2 API in a similar way.- added a commit that references this issue
on Oct 7, 2026
In v2 a session's `slug` is published on the `session.created` event and nowhere else. `SessionInfo` — what `session.get` / `session.list` and `GET /api/session` return — has no `slug` (checked on 2.0.24), no later session event carries it, and a plugin's context has no `session.log` to read the create back from.
So a plugin that identifies sessions by slug loses every session created before the background service last started: after a restart, a resumed session can be fully active and the plugin still has no way to learn its slug. In v1 every `session.updated` carried the full session including `slug`, so this didn't come up.
Ask: add `slug` to `SessionInfo` (it is already on the stored session, since `session.created` emits it).
Context: Tin Can uses the slug as the session's address for cross-session messaging. We currently work around this by having the plugin persist slugs itself, which only covers sessions created while the plugin was installed.