Durable Actor Session Protocol | DASP

DASP

2 min read Original article ↗

Durable Actor
Session Protocol

A server protocol for durable actors.

The connection can end. The work can continue. Discover what an actor offers, send commands, read saved outcomes, and return to the same actor session.

Follow a command Compare protocols

Clients connect through a DASP server.
Web appCLIServiceDASP serverSessions · commands · historyWorkflowactorDeviceactorAgentactor

Capability discovery

Learn before
you open.

An optional setup contract reveals the actor’s exact profile and a bounded view of its commands. A large actor returns stable summary pages. The client reads details and schema resources only for the commands it needs.

Discovery describes commands. It does not authorize them.

Follow discovery
  1. 1

    SelectAuthenticate one exact discovery mapping.

  2. 2

    ListRead bounded summaries from one stable snapshot.

  3. 3

    InspectRequest selected details and exact schema resources.

  4. 4

    ConfirmConfirm the profile, binding, extensions, and limits.

  5. 5

    OpenAssert the profile and start the durable session.

Use the durable session

After setup, five core operations connect your client to the actor’s saved record.

Inspect the messages
Five client operations · short message names
PurposeRequestReply
Open or return to a sessionsession.opensession.opened
Ask the actor to do workcommandreceipt
Read current saved stateview.readview
Read missed eventsupdates.readupdates
Check a command's resultoutcome.readoutcome

Command admission

Know what
the server saved.

The server saves acceptance before replying. It records the final outcome separately. If effects cannot be established, the outcome is uncertain.

Understand the messages
From client intent to a saved outcome.

Stable command IDcmd-042

  1. ClientSubmit a commandKeep its ID and data for retries.

  2. ServerSave admissionThen return an accepted receipt.

  3. ServerSave the outcomeCompleted · failed · cancelled · uncertain

Progress is temporary. The outcome is saved.

Resume after the last applied update.
Before disconnectAfter reconnectCursor: 2Read after 2DASP server · saved session history12345Applied through 2Replay 3–5

Connection recovery

Reconnect to
the same record.

The server retains ordered updates when a connection ends. A returning client reads after the last update it applied.

Read the recovery rules

Shared sessions

Many clients.
One shared session.

A web app, command-line tool, and service can use the same actor session. The server checks access and gives each client the same ordered history.

Understand shared sessions
One history. A position for each client.
DASP serverOne actor session · saved updates12345Same order for every clientWeb appCursor: 5CLICursor: 3ServiceCursor: 4

Common rules.
Native clients.

Choose Elixir or TypeScript. Both use the same messages and recovery rules. Elixir includes a WebSocket client. TypeScript accepts your transport. Your application supplies authenticated setup, profile rules, and durable storage.

Read the specification