Skip to content

Keep hosted channels available when their workspace is offline #179

Description

@iamnbutler

Let a hosted channel remain discoverable and manageable when its workspace is disconnected. Today hosted routing/listing is coupled to its workspace host's catalog and directory snapshot even though durable channel state lives in the cell.

Acceptance

  • Define ownership of the hosted channel's durable identity/location and directory listing separately from the workspace's connection. The directory lists locations and metadata, not channel content; pi owns durable channel state.
  • A workspace going offline does not make a healthy hosted cell disappear or falsely classify its transcript as offline. Surface cell reachability and workspace availability distinctly to clients.
  • Open/read and permitted human chat operations route to the hosted cell while the workspace is unavailable. Tool requests have explicit unavailable/interrupted outcomes; reconnect restores supported tool operation without duplicating execution.
  • Keep name, summary, archived state, owner and location consistent through cell/workspace/client restarts. Define and exercise archive, resume, Kill and Delete when the workspace is absent, including necessary deferred lane cleanup and the preservation guarantees on failure.
  • Preserve the existing ownership/collaborator policy across routes. Directory publication must not let a disconnected/reconnecting workspace overwrite a newer authoritative channel location or revive a deleted channel.
  • Verify with a deployed cell and clients on two actual machines: stop the workspace, continue permitted channel interaction, reconnect it, restart the cell, and confirm history and lifecycle state remain consistent.

This work separates hosted-channel availability from local tool execution; it does not move execution to the cloud. Keep packages/channel runtime-neutral and use shared protocol types. Any durable format change needs a versioned migration and existing-channel backup validation.

Priority 4 under #13; use #176's observed routing/lifecycle failures as evidence. Directory push latency #14, project lobbies #17, execution-host handoff #49, cross-gateway terminals #11 and direct browser access without a gateway remain separate scopes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions