Skip to content

Back up and restore hosted channels #178

Description

@iamnbutler

Provide a documented, exercised per-channel backup and restore path before relying on hosted channels for permanent work. ace backup currently snapshots local SQLite channels; a hosted channel's pi state lives in its cell.

Acceptance

  • Choose and document the recovery mechanism supported by the deployed runtime, including provider-native Durable Object backup/point-in-time recovery where appropriate. Define the recovery scope, retention, consistency and operator prerequisites; do not require a bespoke export API when a provider-native mechanism meets the need.
  • Back up or establish a recovery point for an existing deployed channel, then exercise restoration in an isolated destination or other verified recovery procedure that preserves the source. Verify identity, metadata, chats, messages, child ownership, tool results, usage, model configuration and unfinished/aborted run state.
  • Explain identity/location handling and prevent restored copies from accidentally executing the same channel concurrently. Check interrupted/failed recovery preserves available source data and provides a clear continuation path.
  • Keep project files and lane worktrees explicitly separate from channel-state backup. Record the workspace/path information required for recovery without claiming that backing up the cell saves the checkout.
  • State which recovery/portability needs, if any, require pi state export/import beyond provider-native recovery. Reuse the bounded same-version CLI movement representation from Move channels between local and hosted with the same workspace #181 where appropriate; broader portable recovery stays here. Do not add a second authoritative channel store.
  • Resume real model/tool work after the exercised restoration. Document operator commands, verification steps and limits. Every stored-format change has a versioned migration and a check against an existing-channel backup.

Keep pi-durable authoritative for messages, runs and chats. The acceptance target is a recovery path that operators have actually exercised against real channel state, not the existence of an untested provider feature or a particular custom implementation.

Priority 3 under #13. Pilot #176 provides the first deployed acceptance evidence. The initial idle local ↔ hosted CLI roundtrip in #181 is separate work and has no automatic backup requirement or dependency on this issue, by the user's explicit choice. This issue retains the future backup/restore work; execution-host handoff remains #49.

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