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

Описание и применение

Автоматический мониторинг закрыл задачу за 11 часов, но система учёта оставила её открытой в течение восьми дней из‑за отсутствия входных данных для условия закрытия. Добавление функции fetchOpenHealthIssues() и обновление условия исправило проблему.

Задача

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.

Результат

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

Рабочий процесс

• 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.

Доказательства

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.

Источник

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.

Источник

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.

Источник

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

Источник

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."

Источник