Skip to main content
This page covers the Doctor diagnostic system, which provides automated environment validation and recovery, and the CLI Parity framework, which ensures consistency across the Palyra command-line interface through automated matrix validation and help snapshot testing.

Doctor Diagnostic System

The Doctor system is responsible for inspecting the local environment, identifying configuration drifts, corrupted state files, or connectivity issues, and providing a path to remediation. It operates via DoctorCheck units that can perform both diagnostics and repair actions.

Implementation and Data Flow

The core logic resides in crates/palyra-cli/src/commands/doctor/recovery.rs. The system follows a structured execution flow:
  1. Environment Probing: Captures the current state_root and config_path crates/palyra-cli/src/commands/doctor/recovery.rs#60-64.
  2. Diagnostic Execution: Runs a suite of checks across various subsystems (Auth, Browser, Node, Routines).
  3. Plan Generation: If issues are found, the system generates a DoctorRepairPlan containing specific DoctorRepairStep items crates/palyra-cli/src/commands/doctor/recovery.rs#172-176.
  4. Repair/Rollback: Applies changes to the filesystem, creating backups for every destructive action to allow for later rollbacks crates/palyra-cli/src/commands/doctor/recovery.rs#141-155.

Doctor Execution Model

The system supports multiple execution modes defined by DoctorExecutionMode crates/palyra-cli/src/commands/doctor/recovery.rs#66-74:
  • Diagnostics: Read-only inspection.
  • RepairPreview: Generates a plan without applying changes (Dry Run).
  • RepairApply: Executes the remediation steps.
  • RollbackApply: Reverts a previous Doctor run using the stored DoctorRecoveryManifest.

Key Components & Entities

EntityDescriptionLocation
DoctorCommandRequestCLI arguments for the doctor command (strict, repair, force, etc.)crates/palyra-cli/src/commands/doctor/recovery.rs#48-57
DoctorExecutionReportThe final output containing both diagnostics and recovery results.crates/palyra-cli/src/commands/doctor/recovery.rs#76-83
DoctorRecoveryManifestA JSON file tracking changes made during a repair for rollback purposes.crates/palyra-cli/src/commands/doctor/recovery.rs#141-155
DoctorRepairKindEnum defining specific repair logic (e.g., MigrateConfigVersion, BackfillAccessRegistry).crates/palyra-cli/src/commands/doctor/recovery.rs#178-237

Doctor Diagnostic Logic Flow

The following diagram bridges the diagnostic logic to the code entities that manage state and recovery. “Doctor Diagnostic & Recovery Flow” Sources: crates/palyra-cli/src/commands/doctor/recovery.rs#8-102, crates/palyra-cli/src/commands/doctor/recovery.rs#141-176

CLI Parity Matrix

Palyra maintains a strict parity matrix to ensure that the CLI surface remains consistent across updates and platforms. This is enforced through automated tests that compare the live clap command tree against a canonical matrix definition.

Parity Verification Framework

The parity system uses a CliParityMatrix crates/palyra-cli/src/cli_parity.rs#96-99 defined in tests/cli_parity_matrix.toml.

Help Snapshot Testing

To prevent regressions in documentation and UI, the CLI uses help snapshot testing. Each entry in the parity matrix can point to a snapshot file crates/palyra-cli/src/cli_parity.rs#30-38.

CLI Parity Architecture

“CLI Parity Validation System” Sources: crates/palyra-cli/src/cli_parity.rs#155-200, crates/palyra-cli/tests/cli_parity.rs#56-70

Remote Diagnostics (Console API)

The daemon provides an HTTP interface for the Web Console to interact with the Doctor system. This allows operators to run diagnostics and view recovery jobs remotely. The daemon-side jobs are synchronized with the CLI’s DoctorExecutionReport structure to ensure parity between local and remote management. Sources: crates/palyra-daemon/src/transport/http/handlers/console/doctor.rs#1-46, crates/palyra-cli/src/commands/doctor/recovery.rs#77-83