Skip to content

bug: worker spawn OSError crashes CLI with raw traceback after run is durably committed to the queue #38

Description

@Adityakk9031

What happened?

When running codealmanac init, codealmanac ingest, or codealmanac garden, the CLI writes the run records durably to the SQLite database with status=queued. It then calls subprocess.Popen(...) to spawn the background worker.

If spawning the worker raises an OSError (due to a missing python interpreter path, permission issues, or system limits), the exception propagates uncaught. Since cli/main.py only handles CodeAlmanacError and ValidationError, the CLI crashes with a raw Python stack trace.

Furthermore, the run record remains stuck in status=queued in the SQLite database permanently, leaving an orphaned job that cannot execute or automatically recover.

What did you expect?

The CLI should catch the spawn failure gracefully, print a clean codealmanac: error message, and instruct the user on what happened and how to recover (e.g., that the run was queued, but the worker failed to start).

Reproduction

  1. Trigger an OSError during spawn_worker (e.g., by running in an environment where sub-processes are blocked or python is not on the path).
  2. Run a lifecycle command:
    codealmanac init .

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    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