Skip to content

feat(#591 followup): cron-prompt error semantics for Monitor-failure case #597

Description

@michael-wojcik

Surfaced during PR #596 blind review (backend-F1).

Problem: The cron prompt body's Branch A cold-start path tells the LLM to spawn Monitor, capture M_ID, then write STATE_FILE referencing M_ID. The FAIL-OPEN clause says "log + continue" on tool errors — but if Monitor itself fails to spawn (resource exhaustion, platform unavailability), M_ID is undefined.

Failure shape: LLM either writes a malformed STATE_FILE (M_ID = error string or empty) OR skips the STATE_FILE write entirely. Next cron-fire's branch detection becomes inconsistent (state-file present but invalid; or state-file missing → cold-start → likely fails again).

Why deferred: fix is non-trivial (cascading error handling). Risk of half-fixing creates worse semantics than the current FAIL-OPEN. CronCreate/Monitor failures are edge-of-edge in practice.

Suggested fix scope: explicitly enumerate the cascade — if Monitor fails, do NOT write STATE_FILE; log error; rely on next cron-fire's Branch A retry. Specify the exact line in cron prompt body.

Originating review: docs/review/591-blind-backend.md FUTURE-1.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions