Skip to content

feat: bump default execution timeout 15min → 60min (#665) - #841

Merged
vybe merged 2 commits into
devfrom
feature/665-default-timeout-60m
May 14, 2026
Merged

feat: bump default execution timeout 15min → 60min (#665)#841
vybe merged 2 commits into
devfrom
feature/665-default-timeout-60m

Conversation

@dolho

@dolho dolho commented May 14, 2026

Copy link
Copy Markdown
Contributor

Summary

Default chat/task execution timeout was 15min (900s). Long research runs, multi-step code generation, and batch processing routinely hit the wall — the silent truncation looks like success until the user notices. 60min matches the upper bound of what agents are expected to do autonomously.

Per-agent override at PUT /api/agents/{name}/timeout (range 60–7200s) unchanged; only the default moves.

Scope (slight extension over issue text)

Column Before After
agent_ownership.execution_timeout_seconds 900 3600
agent_schedules.timeout_seconds 900 3600

Issue text only specified the agent column. But the watchdog query at db/schedules.py:1800 resolves timeout via COALESCE(s.timeout_seconds, ao.execution_timeout_seconds, 3600) — without bumping the schedule column too, new scheduled tasks would pick up 900 from the per-schedule override before the agent's 60min default kicked in. The PR fixes both for consistency.

Migration

_migrate_default_execution_timeout_to_3600:

  • UPDATE agent_ownership SET execution_timeout_seconds = 3600 WHERE execution_timeout_seconds = 900
  • Same for agent_schedules.timeout_seconds
  • Operator-customised values (everything except 900) untouched.
  • Idempotent.

SQLite gotcha + explicit INSERT

SQLite stores column DEFAULTs at column-creation time. Changing DEFAULT 900 to DEFAULT 3600 in schema.py only affects fresh installs — on existing instances the column still has 900 baked in, so new INSERTs without explicit value pick up 900.

Fix: register_agent_owner now passes execution_timeout_seconds = 3600 explicitly on INSERT. Works on both fresh and upgraded installs.

Files

  • src/backend/db/schema.py — both column defaults
  • src/backend/db/migrations.py — bump migration
  • src/backend/db/agents.py — explicit INSERT value (the load-bearing fix on upgraded installs)
  • src/backend/db/agent_settings/resources.py — COALESCE fallbacks + docstrings + return-default → 3600
  • src/backend/db/schedules.py — row-to-Schedule fallback + watchdog COALESCE final fallback
  • src/frontend/src/components/SchedulesPanel.vue — 4 form-defaults + dropdown "(default)" label moved to 1 hour
  • src/frontend/src/components/TasksPanel.vue — localStorage fallback

Live verification

1. Backend reloaded → migration ran
2. Pre-existing rows: 13 at 900 → 0 at 900, 13 moved to 3600 ✓
3. New agent created post-PR: execution_timeout_seconds = 3600 ✓
4. Per-agent override (PUT /timeout) still validates range 60–7200s ✓

Test plan

  • Migration runs cleanly on backend reload
  • Existing 900-rows bumped to 3600 in both agent_ownership and agent_schedules
  • New agents inserted via API get 3600 explicitly
  • Per-agent timeout override still works
  • UI dropdown shows "1 hour (default)" instead of "15 minutes (default)"
  • CI: lint + 6-seed pytest matrix + regression diff

Closes #665

🤖 Generated with Claude Code

Real-world agent tasks routinely exceed the 15min default — long
research runs, multi-step code generation, batch processing all hit
the wall. Result is a silent truncation that looks like a successful
completion until the user notices the cut-off output. 60min aligns
with the upper bound of what agents are expected to do autonomously.

Per-agent override (PUT /api/agents/{name}/timeout, range 60–7200s)
is unchanged; this only moves the default.

Scope

- `agent_ownership.execution_timeout_seconds` DEFAULT 900 → 3600
  (schema.py)
- `agent_schedules.timeout_seconds` DEFAULT 900 → 3600 (schema.py).
  Issue text only mentioned the agent column, but the watchdog query
  in `db/schedules.py:1800` does
  `COALESCE(s.timeout_seconds, ao.execution_timeout_seconds, 900)`,
  so without bumping the schedule column too, new scheduled tasks
  would still pick up 900 from the per-schedule override even on
  agents with the new 60min default.

Migration (`default_execution_timeout_to_3600`)

- `UPDATE agent_ownership SET execution_timeout_seconds = 3600 WHERE
  execution_timeout_seconds = 900` — bumps every row still at the
  old default. Operator-customised values (everything except 900)
  are untouched. Same one-liner for `agent_schedules.timeout_seconds`.
- Idempotent.

Backend register-time wiring

- `register_agent_owner` now passes `execution_timeout_seconds = 3600`
  explicitly on INSERT. SQLite bakes column DEFAULTs at column-
  creation time and doesn't honour later DDL — on instances that
  already had the column with `DEFAULT 900`, new agents would still
  get 900 unless we pass the value. This makes the bump effective
  on every install, fresh or upgraded.

Other call sites updated for consistency

- `db/agent_settings/resources.py`: COALESCE fallback + docstrings
  + return-default → 3600.
- `db/schedules.py`: row-to-Schedule fallback (line 95) + watchdog
  COALESCE final fallback (line 1800, used only when both
  schedule and agent columns are NULL — defensive).

Frontend

- `SchedulesPanel.vue`: 4 sites where 900 was the form-default →
  3600. Dropdown's "(default)" label moved from 15min to 1 hour.
- `TasksPanel.vue:579`: localStorage fallback for the chat-task
  timeout picker → 3600.

Live verification

- Migration ran on backend reload: 13 existing agents at 900 → all
  moved to 3600. 0 rows left at 900.
- Created new agent post-PR: `execution_timeout_seconds = 3600` ✓
- Per-agent override (PUT /timeout) still works in range 60–7200s.

Related to #665

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@dolho
dolho requested a review from vybe May 14, 2026 11:34
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@vybe
vybe merged commit 186827f into dev May 14, 2026
10 checks passed
AndriiPasternak31 added a commit that referenced this pull request May 17, 2026
Brings in 11 commits since the previous rebase (ba4aeae09c8bec),
including the SITE-001 revert (#867), the cleanup retention status-value
fix (#864), and the 60-min default execution timeout (#841).

Conflict resolved: src/backend/db/migrations.py — kept dev's two new
migration entries (default_execution_timeout_to_3600,
fix_retention_index_status_values) first, then our execution_retry_count
appended. All three migration functions defined; order matches each
side's landing chronology.

Phase A (test_cleanup_unreachable_orphan.py helper-pair) and Phase B
(tests/unit/conftest.py baseline-restore) for #797 verified intact after
auto-merge. Lint clean, voice_auth + cleanup tests pass under seed 12345.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants