Enabled hourly automation has no next run or inspectable execution history

Summary

A recurring ChatGPT automation can remain reported as enabled while exposing no next scheduled run. The available task record also exposes a last-run timestamp but no run/fetch history sufficient to determine what the condition watch checked or whether the run succeeded.

Environment

• ChatGPT iOS app 1.2026.237 (build 33230022603)
• iOS 27.0
• Personal timezone: America/Los_Angeles
• Automation type: recurring hourly condition watch

Observed state

• is_enabled: true
• Schedule contains RRULE:FREQ=HOURLY
• A concrete last_run_time is present
• next_run_time: null
• The task listing exposes no per-run source calls, fetched items, success/failure result, or notification disposition
• A top-level completed_count: 0 is ambiguous and should not be interpreted as the task's execution count

Private conversation IDs, task IDs, account details, and evidence contents are intentionally omitted.

Steps to reproduce

1. Create an hourly recurring condition-watch automation in ChatGPT.
2. Allow it to run at least once.
3. Inspect its task state after the run.
4. Observe that the automation can remain enabled while next_run_time is null.
5. Attempt to inspect the previous run and determine which sources were queried and whether a notification was suppressed.
6. Observe that no adequate per-run execution record is exposed.

Expected behavior

• An enabled recurring task with an hourly RRULE should expose a future next-run time, or a clear diagnostic explaining why it has none.
• Each run should expose a bounded status record: start/end time, success/failure, tools or source categories accessed, whether the condition matched, and whether a notification was emitted or suppressed.
• Aggregate fields such as completed_count should be clearly scoped and labeled.

Actual behavior

The automation is marked enabled and has a recorded last run, but no next run is displayed and the prior run cannot be reconstructed from the exposed state.

Evidentiary note

This report does not claim that no fetch occurred. It reports that the available task state does not establish what was fetched, returned, or notified.

Related issue

Possibly related to #38350, but this report focuses on the inconsistent enabled/next-run state and missing per-run observability rather than automatic pausing.

No repository files, tests, or entry points are named. Start by locating the automation task-state and recurring-schedule implementation, then inspect existing tests for next-run calculation and execution records; done means enabled hourly tasks expose a valid next run or diagnostic, and prior runs expose the requested bounded status fields.