This report describes a scheduler reliability bug: scheduled tasks can be saved successfully but later fail at runtime with “No model configured” when relying on the app’s default model, indicating inconsistent model resolution across task creation, persistence, and execution.

Title: [Bug] Scheduled tasks can fail with “No model configured” when relying on default model; model resolution is inconsistent across create/save/run paths

Type: Bug

Summary Scheduled tasks / cron jobs in Alma may fail at execution time with the error No model configured, even when the user already has a valid default model configured in Alma and the task appears otherwise valid.

This suggests the scheduler pipeline does not consistently resolve or persist the model across task creation, editing, persistence, and execution.

Environment

• App: Alma 0.0.724

• OS: macOS 26.3.1

• Arch: arm64

Privacy / Redaction

• Provider names, account identifiers, local paths, thread IDs, and any credentials have been redacted.

• No secrets are included in this report.

Severity Medium-High

Why this matters This is not just a UX issue:

1. A scheduled task can be created/saved successfully but still fail only at runtime.

2. Failure happens in unattended/background execution, so users may assume automation is working when it is not.

3. The error is generic and appears too late, which makes diagnosis difficult.

4. It breaks trust in scheduled workflows such as daily reports, monitoring, and recurring assistant tasks.

Observed behavior A scheduled task that should inherit or use an available model fails during execution with: No model configured

In testing, manually forcing a model into the task payload can make the task run again, which strongly suggests the model resolution / persistence logic is inconsistent.

Expected behavior A scheduled task should never reach runtime with an unresolved model if:

• the task explicitly specifies a model, or

• Alma has a valid default model that is intended to be inherited.

If neither is available, Alma should block save/enable at configuration time with a clear validation error, instead of allowing a delayed runtime failure.

Reproduction steps

1. Configure Alma with a valid default chat/model setup.

2. Create or update a scheduled task / cron-style task.

3. Do not explicitly hardcode a model into the task payload, and instead rely on Alma’s current/default model behavior.

4. Wait for the task to execute automatically.

5. Observe that the run may fail with: No model configured

Likely variants

• Create task under one model context, then later change default model.

• Edit an existing scheduled task from the UI without re-binding the model explicitly.

• Task metadata and execution payload do not carry the same model field or source of truth.

Actual result

• Task is accepted/saved.

• Runtime execution fails with No model configured.

Expected result

• The task should inherit a valid model deterministically, or

• Alma should reject/disable the task before runtime with a clear validation message.

Suspected root cause The bug appears to be a model-resolution inconsistency between one or more of these stages:

1. Task creation

2. Task editing

3. Task persistence/serialization

4. Scheduler runtime execution

Most likely failure modes:

• The UI stores model information in one field, but the executor reads another.

• The scheduler expects an explicit task-level model and does not reliably fall back to the app/workspace default model.

• The saved payload is not normalized, so model information can exist in one path but be absent in the runtime path.

• Validation is deferred until execution instead of enforced at save/enable time.

Design / implementation concern The installed macOS app is packaged as a bundled app.asar build, so field-level hotfixing and verification directly inside Alma.app is difficult and brittle in production installs. Even if a local patch is attempted, it is not a reliable or supportable fix path for users.

That is not the primary bug, but it increases support/debug cost significantly:

• runtime investigation is harder,

• source of truth is harder to trace from the packaged app,

• users cannot reasonably self-recover.

Recommended fix

1. Introduce a single canonical model-resolution function for scheduled tasks:

   • explicit task model

   • task payload model

   • workspace/thread-level model

   • current default model

   • otherwise fail validation before scheduling

2. Normalize model fields on save/edit so the executor and UI read the same structure.

3. Validate scheduled tasks at creation/update time:

   • if no resolvable model exists, prevent enabling/saving and show a clear message

4. Add runtime diagnostics:

   • log which resolution layer was attempted

   • distinguish “task missing model” vs “default model missing” vs “provider/model unavailable”

5. Add regression tests covering:

   • new task with explicit model

   • new task inheriting default model

   • edited task after default model changes

   • migrated/legacy scheduled task records without explicit model fields

Suggested acceptance criteria

• A scheduled task with a valid default model no longer fails with No model configured.

• Save/edit/runtime all resolve model through the same logic.

• If no model is resolvable, the UI blocks configuration before runtime.

• Existing scheduled tasks created under older versions are either migrated or handled gracefully.

Workarounds observed Temporary workaround:

• explicitly write/bind the model into the scheduled task payload

Why workaround is insufficient:

• fragile

• easy to regress on edit

• not discoverable

• unsuitable for normal users

Requested action Please treat this as a scheduler reliability bug rather than a simple configuration mistake. The product should guarantee deterministic model resolution for unattended tasks and fail early when configuration is invalid.