Skip to content

service: sessions are not grouped or parented under the service that created them #1134

Description

@edwin-zvs

Service sessions are created with parent_session_id: None and group_id: None (crates/daemon/src/service/ingress.rs), so they land in the fleet as flat, unattributed sessions. Nothing in a client indicates which service produced a session, or that a session came from a service at all.

The design says service sessions "appear in clients, grouped or parented under their service, and the owner can open one and participate while channels keep flowing through it". The second half works — they are real fleet sessions and the owner can open and drive them. The attribution half does not.

The cost is not cosmetic: a service under keyed routing accumulates one session per key, and with per-event routing one per request (which are also never archived — see #1135). Those fill the session list with no indication of origin, which is also what makes the missing archive step painful.

Grouping vs. parenting is the design call. A group reads naturally for "these all belong to service X". Parenting under a service has no obvious parent session to hang from unless the context session (#1131) becomes one.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions