Skip to content

fix(scheduler): arm held capacity credits at dispatch #64

Description

@DavidBellamy

Context

Comet reserves one scheduler-backed SMG capacity credit before the client sends inference. The bearer has a bounded 30 second presentation lifetime, which correctly prevents abandoned clients from leaking capacity, but the dispatch path needs a way to start that short presentation window only when the proxy is ready to forward.

Goals

  • Keep the existing scheduler permit and immutable fair-share binding.
  • Add an authenticated one-shot arm operation that refreshes the active credit presentation deadline immediately before dispatch.
  • Preserve bounded expiry, cancellation, redemption, proof minting, and exact settlement.
  • Make an idempotent retry return the same armed deadline without extending it again.

Non-goals

  • No new scheduler capacity.
  • No change to tenant ordering or adaptive admission.
  • No client-facing bearer issuance.

Proposed design

Add an internal arm route for an active unredeemed capacity credit. The registry transitions ActiveUnarmed to ActiveArmed and replaces its initial deadline with one fresh TTL. A repeated arm of the same active record is idempotent and does not move the deadline. Expired, cancelled, redeemed, wrong-generation, or binding-mismatched records fail closed. Redemption remains the only operation that transfers the held scheduler permit into request execution.

Safety and tests

  • Immutable generation, tenant, model, partition, request ID, estimate, and policy epoch binding.
  • Concurrent arm calls yield one transition and one fixed deadline.
  • Arm cannot resurrect expired or terminal records.
  • Cancellation and expiry release the permit exactly once.
  • Existing v1 issue/redeem behavior remains unchanged.
  • Metrics distinguish armed, arm retry, and arm rejection.

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