Skip to content

Detect and self-recover a live scheduler that stops dispatching provider creates #146

Description

@rldyourmnd

Problem

A production control plane remained active/running and continued serving metadata and callbacks, but newly persisted pending_create instances stopped reaching provider create. Restarting only the manager service immediately resumed dispatch. This is a portable scheduler liveness defect: process health is not scheduler progress.

No private repository, host, address or credential is required to describe the failure.

Required behavior

  • persist scheduler progress/heartbeat independently from HTTP process health;
  • detect queued create work whose dispatch age exceeds a bounded threshold while provider capacity is eligible;
  • restart or reconstruct the affected worker loop idempotently without restarting unrelated services;
  • never create a duplicate active worker during recovery;
  • expose unhealthy, recovering and recovered states in metrics/logs;
  • preserve the original intent and attempt history;
  • add deterministic restart/replay tests and a natural-job canary.

Acceptance

A fault-injected stopped dispatcher recovers without operator restart, every accepted intent reaches one terminal outcome, and the test proves zero duplicate provider create or double release.

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