Skip to main content

Module command_registry

Module command_registry 

Source
Expand description

Command registry abstraction for command server

The CommandRegistry is the source of truth for all command metadata. It tracks command state, timestamps, sizes, and errors.

Implementations:

  • InMemoryCommandRegistry: In-memory implementation for tests and local dev (in this crate)
  • PlatformCommandRegistry: Platform API integration (in alien-manager)

The command KV store holds only operational data: params/response blobs, pending indices, leases.

Structs§

CommandEnvelopeData
Data needed to build an envelope during lease acquisition
CommandMetadata
Metadata returned when creating a command
CommandStatus
Full status for GET /commands/{id}
InMemoryCommandRegistry
In-memory implementation for tests and local development.
ResolvedCommandTarget
A command target resolved by the registry, plus how commands reach it.

Traits§

CommandRegistry
Abstraction for command metadata storage and lifecycle tracking.

Functions§

delivery_mode_for
Pinned per-type delivery rule — the single implementation both registries route through. Container and Daemon targets are always Pull; a Worker target follows worker_mode, the caller’s derived worker context (production: Push only when the platform has a push path AND stack_settings.deployment_model is Push).
select_command_target
Target-selection rules shared by both the in-memory and SQLite registries route through.
validate_command_name
Reject a command name that would break the same :-delimited idempotency key grammar ({dep}:{rid}:{command}:{key}).
validate_command_target_id
Reject a command-target resource id that would break the :-delimited key grammar used by the pending index (target:{dep}:{rid}:pending:…) and the idempotency key ({dep}:{rid}:{command}:{key}).