Task

Единица работы каждого запуска agent — state machine, таймауты и правила retry.

Task — единица каждого запуска agent: назначение issue agent, @-упоминание agent в комментарии, сообщение в chat или срабатывание Autopilot по расписанию — всё это создаёт task. Multica ставит его в очередь; daemon забирает и передаёт соответствующему AI coding tool, затем записывает результат на сервер по завершении.

Task и issue — разные объекты. Один issue можно назначить, @-упомянуть и вручную rerun много раз — каждый раз создаётся новый task.

Состояния task

Rendering diagram…

Queued — task только что создан и ждёт, пока daemon его заберёт
Dispatched — daemon забрал task и запускает AI coding tool
Running — AI coding tool выполняет работу
Completed — успешно завершён; результат (комментарии, коммиты, смена статуса) записан на сервер
Failed — прерван с ошибкой или по таймауту; если причина retryable, task автоматически возвращается в queued для повторной попытки
Cancelled — отменён пользователем

Таймауты task

Сервер Multica сканирует каждые 30 секунд. Два вида таймаута переводят task в failed:

Situation	Timeout
Dispatched, но не стартовал (daemon забрал, но не запустил AI tool)	5 минут
Running слишком долго	2,5 часа

Оба используют причину timeout и retry автоматически (следующий раздел). Связанная проверка missing runtime — в Daemon and runtimes → When a runtime is marked offline.

Какие сбои retry автоматически, какие нет

Сбои делятся на retryable и non-retryable.

Retryable (Multica автоматически ставит в очередь снова):

runtime_offline — daemon стал missing после dispatch
runtime_recovery — daemon упал и перезапустился, reclaim незавершённых task
timeout — таймаут runtime или dispatch

Non-retryable (task остаётся failed):

agent_error — сам AI coding tool сообщил об ошибке (API error, quota exceeded, internal bug). Базовые проблемы не retry — иначе бесконечный цикл.

У автоматического retry два дополнительных условия:

Не более 2 попыток — 1 исходная + 1 retry. Если retry тоже failed, дальнейших retry нет, даже если причина retryable.
Только для task от issue и chat — task от Autopilot не retry автоматически.

Task от Autopilot не retry автоматически по задумке. У Autopilot свой cadence (например, ежедневно); автоматические retry при сбое пересеклись бы со следующим запланированным запуском. Для немедленного повторного запуска после сбоя используйте manual rerun (следующий раздел).

Как узнать, что task Autopilot failed: уведомление попадает в Inbox, а статус связанного issue откатывается с in_progress на todo. На странице Autopilots также виден последний результат запуска.

Manual rerun vs automatic retry

Manual rerun — вы запускаете из CLI или API (POST /api/issues/{id}/rerun):

multica issue rerun <issue-id>

Поведение:

По умолчанию берёт текущего assignee issue — удобно, когда rerun должен следовать текущему назначению, независимо от того, кто выполнял предыдущий task.
Кнопка retry в execution log на конкретной строке отправляет task ID этой строки — rerun нацелен на agent, который выполнял именно этот task, а не на текущего assignee. Это делает per-row retry осмысленным для squad worker, параллельных @-mention agent или строк, чей agent уже сменился после reassignment.
Отменяет queued или running task целевого agent на этом issue (если есть). Task других agent на том же issue (например, параллельные @-mention) не трогаются.
Создаёт совершенно новый task — счётчик попыток сбрасывается на 1, даже если исходный task достиг потолка попыток.
Запускает новую session agent — session ID предыдущего не наследуется. Manual rerun означает, что вы сочли предыдущий результат плохим; resume той же беседы воспроизвёл бы тот же «отравленный» контекст. (Automatic retry, напротив, наследует session — этот путь для инфраструктурных сбоев, а не плохого output.)

Сравнение:

Dimension	Automatic retry	Manual rerun
Trigger	Система, по причине сбоя	Вы, вручную
Ceiling	2 попытки	Без лимита
Applicable sources	Issue, chat	Issue с agent assignee
Agent picked	Тот же agent, что и failed task	Agent исходного task (UI per-row retry) или текущий assignee issue (CLI / без task_id)
Session inheritance	Да (resume prior session)	Нет (fresh session)

Как failed task влияет на статус issue

Если task от issue failed (и automatic retry не помог), потому что issue был назначен agent, статус issue автоматически откатывается с in_progress на todo — на board сразу видно «этот нужно пересмотреть». См. Issues and projects.

Может ли task продолжить предыдущий контекст

Да — если AI coding tool поддерживает session resumption.

Multica фиксирует session ID дважды за task: в начале (когда AI tool возвращает первое system message) и в конце (при completion или failure). Первый позволяет daemon восстановиться при crash mid-run; второй зарезервирован для следующего automatic retry, где этот ID передаётся обратно, чтобы agent продолжил беседу и состояние файлов. Manual rerun намеренно пропускает это и стартует fresh session — см. Manual rerun vs automatic retry.

Но какие AI coding tools реально поддерживают это — сильно различается:

✅ Real support — Antigravity, Claude Code, Codex, Copilot, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
❌ No support — Gemini

См. Providers Matrix → Session resumption.

Providers Matrix — различия возможностей 12 AI coding tools (включая точный статус session resumption)
Assigning issues to agents / @-mentioning agents in comments / Chat / Autopilots — четыре способа создать task