The pending state nobody lists

Description and use

A script scans blocked tasks, classifies them, and outputs a CSV to prevent hidden inventory.

Problem

When a scheduler’s acceptance gate blocks a task, the task remains in a state between registered and accepted, appearing as "Ready" to the scheduler but actually pending, leading to untracked inventory of blocked tasks.

Outcome

The sweep script now reliably identifies pending, accepted later, and orphan tasks, preventing hidden inventory buildup and enabling proactive cleanup. It also surfaced a header-count bug, improving data accuracy.

Workflow

• 1. Scan the directory of acceptance receipts for entries ending with "acceptance pending".
• 2. For each receipt, extract the task name and query the scheduler for its last run status and result.
• 3. Determine the verdict: ‘pending’ if the task has never run successfully since the block, ‘accepted later’ if it ran clean after the block, or ‘orphan’ if the task no longer exists.
• 4. Write one CSV row per blocked task with columns for task name, last run, last result, and verdict.
• 5. Run the script weekly alongside the census of waiting-class jobs.
• 6. Apply a kill criterion: if four consecutive weeks produce an empty list, downgrade the pending list to on-demand.
• 7. Log and review any orphan entries to reconcile paper trail and reality.

Evidence

The gate shipped with a debt. Today's instrument collects it: a small script that sweeps the acceptance receipts for the blocked line, asks the scheduler for each named task's last run and last result, and writes one CSV row per blocked task.

Source

The instrument also proved honest in development — the first run missed the real pending entirely, because the receipt pattern didn’t match the classifier's actual filename and the task name carried a state suffix.

Source

The sweep now runs beside the weekly census of waiting-class jobs, and the pending list has its own kill criterion: four consecutive weeks of empty lists and it degrades to on-demand.

Source