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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions