3.3 KiB
ADDED Requirements
Requirement: Assignment and device reservation are atomic
The scheduler SHALL atomically bind a queued task to one eligible device, create a bounded lease attempt, and reserve that device so no other active task can be assigned to it.
Scenario: Scheduler assigns an idle device
- WHEN a queued task matches an idle pooled device with no active reservation
- THEN one transaction records the assigned task, owning host/device, incremented attempt, lease identifier, lease expiry, and device reservation
Scenario: Later scheduler iteration sees stale idle snapshot
- WHEN the host snapshot still reports a device idle but that device has an active assignment lease
- THEN the scheduler excludes the device from candidates for every other queued task
Requirement: Host claim transitions assigned work to dispatched
The scheduler repository SHALL allow only the authenticated owning host to atomically claim an unexpired assigned attempt and transition it to dispatched.
Scenario: Owning host claims once
- WHEN the owning host requests available work and an unexpired assigned attempt exists
- THEN exactly one request receives the assignment and its status becomes dispatched
Scenario: Concurrent claims race
- WHEN multiple requests concurrently attempt to claim the same assignment
- THEN at most one request succeeds and every other request receives no assignment or a conflict
Requirement: Expired attempts follow bounded retry policy
The system SHALL detect expired assigned or dispatched leases and SHALL either requeue the task with its reservation released or mark it failed when the configured attempt limit is reached.
Scenario: Lease expires with attempts remaining
- WHEN an active lease expires before a terminal result and the task has remaining attempts
- THEN the task returns to queued, the previous device reservation is released, and the expired attempt remains auditable
Scenario: Lease expires at attempt limit
- WHEN an active lease expires and the task has reached its maximum attempts
- THEN the task becomes failed with a lease-expiry reason and its device reservation is released
Requirement: Terminal transitions validate the active lease
The system SHALL accept a done or failed result only from the current active task attempt and lease and SHALL make repeated identical terminal reports idempotent.
Scenario: Active lease reports completion
- WHEN the active lease owner reports a terminal result
- THEN the task transitions once to done or failed and releases its device reservation
Scenario: Superseded lease reports completion
- WHEN a result references a lease superseded by expiry and retry
- THEN the result is rejected and cannot overwrite the current task attempt
REMOVED Requirements
Requirement: Remote assignments are rejected explicitly, not silently ignored
Reason: Remote execution is now performed by the authenticated Host Agent that owns the assigned device, so rejecting every non-local assignment prevents the intended cloud execution loop.
Migration: Direct callers may continue using TaskDispatcher for local assignments, but cross-host work SHALL be delivered through the Host Agent lease/claim protocol instead of calling a dispatcher in the control-plane process.