A monitor closed its own issue in 11 hours. A ledger called it open for 8 days.

Description and use

An automated monitor closed an issue in 11 hours, yet the ledger still marked it unresolved for eight days because the close condition lacked necessary input. Adding fetchOpenHealthIssues() and updating the condition resolved the issue.

Problem

An automated monitoring workflow closed a GitHub issue, but the ledger tracking automated work still marked it unresolved for eight days because the close condition lacked the necessary input context.

Outcome

Adding the missing context function and updating the close condition restored the ledger’s ability to clear resolved issues, preventing stale rows from persisting.

Workflow

• 1. Monitoring workflow opens issue #591.
• 2. Monitoring workflow closes issue #591 11 hours later.
• 3. Ledger’s issue_closed condition runs daily but receives an empty input, returning "cannot determine".
• 4. Row remains unresolved in the ledger’s unprocessed queue.
• 5. Implement fetchOpenHealthIssues() to provide the list of open health‑labelled issues.
• 6. Update issue_closed to use the fetched list and handle API failures by returning null.
• 7. Verify the condition distinguishes between closed, open, and API‑unavailable states via mutation testing.
• 8. Confirm the ledger row clears when the issue is truly closed.

Evidence

The monitoring workflow in this project opened issue #591 at 03:42:15Z on 2026-08-26. The same workflow closed it at 14:31:44Z, about eleven hours later, the same day.

Source

The ledger carries a close condition for exactly this case: issue_closed, which is supposed to look up the GitHub issue's current state and clear the row once the issue is no longer open.

Source

The condition existed from the day the issue-closed check was written. What it needed was a context object listing the open health issues to check against. Nothing ever built that object.

Source

The fix was a function, fetchOpenHealthIssues(), that the close condition had been missing from the start.

Source

The function also had to decide what to return when the GitHub API itself was unreliable — no token, a non-200 response, an exception, or more open issues than fit on one page. Any of those map to null, not to "no open issues."

Source