jpmschweitzerandClaude e45de4fec7 fix(orchestrator): record the terminal states that were never written
Two defects with one shape: an execution reaches a terminal condition and the
orchestrator fails to write it down, so the system's own record disagrees with
what happened. Neither produced an error. Both produced silence.

T-2 -- a restart mid-task unscheduled that task forever.

get_tasks_for_minute excludes any task holding a task_executions row with
status='running'. The row is written before the executor runs and updated
after, so a process dying in between left it 'running' permanently, and the
task was then excluded from every future minute with no error, no alarm and no
log line. It did not fail; it went quiet.

test_example_task had held such a row since 2025-12-07 -- 5916 hours. It is
disabled, so nothing was broken by that instance; the mechanism is the point,
and the exposure is daily, because Watchtower restarts this container at 4 AM
while the config backup starts at 03:05 and runs ~21 minutes.

Startup now reconciles them, where the reasoning is sound by construction: this
process has just begun, so nothing it can see is genuinely running.

Marked 'orphaned', not 'failed'. When the process dies mid-task the work may
well have completed -- a backup that finished and never got to update its row
is indistinguishable from one that died halfway -- and 'failed' would assert an
outcome nobody observed. Same error as the health-report diagnostic fixed in
18be804: naming a cause you did not witness.

Not extended to a duration-based sweep. While this process lives, execute_task's
finally clause always closes the row, so a stale row implies a dead owner. A
time-based rule would have to tell a slow task from a dead one, and getting that
wrong closes the record of a task still working.

T-3 -- the 'timeout' status was unreachable.

execute_task has an `except asyncio.TimeoutError` branch that records
status='timeout'. It could never run: _run_executor wrapped the awaited call in
`except Exception`, and since 3.11 asyncio.TimeoutError IS the builtin
TimeoutError (OSError -> Exception), so the broad handler caught it first and
converted it to an ordinary error tuple. Confirmed in the deployed runtime and
against the history -- 18,785 executions since 2025-12-07, of which 'timeout'
rows: zero. Every timeout in eight months was filed as a generic failure,
erasing the distinction between "too slow for its window" and "broken".

A narrower except after a broader one is dead code, and no linter is configured
here to say so.

One trap in fixing it: while the branch was unreachable a timeout travelled the
normal path, which DOES update scheduled_tasks. Making the branch reachable
without that write would have traded a wrong status for a stale one, so
_update_task_outcome now mirrors terminal outcomes onto the parent row.

The timeout message also states that the work may still be running -- after
T-74 executors are handed to asyncio.to_thread, and a thread cannot be
cancelled, so wait_for frees the loop while the work continues.

Both fixes are mutation-checked: removing the startup call fails the ordering
test, removing the narrow except clause fails the propagation test. Suite goes
118 -> 126 passing with the same 36 pre-existing failures.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-11 12:09:35 +02:00
2026-08-11 11:35:29 +02:00
2026-08-11 11:35:29 +02:00

The Scheduler

System-wide maintenance orchestration for automated task scheduling.

The Scheduler is a hybrid APScheduler + PostgreSQL-based task scheduling system that handles backups, documentation mirroring, cleanup, and automated maintenance tasks across the Portainer Core infrastructure.

Architecture

Hybrid Design: APScheduler + Database-driven Priority System

┌─────────────────────────────────────────────────────────┐
│  APScheduler (runs every minute)                        │
│  └─> Query PostgreSQL for tasks scheduled this minute   │
│      └─> Execute up to 5 tasks concurrently by priority │
└─────────────────────────────────────────────────────────┘

Key Features:

  • Minute-based scheduling with cron-like patterns (-1 = wildcard)
  • Priority queue (1-100, lower = higher priority)
  • Concurrent execution (max 5 tasks simultaneously)
  • Execution tracking (full audit trail in database)
  • REST API for task management
  • Flexible executors (modular task implementations)

Quick Start

Starting the Scheduler

# Deploy via Portainer
# Uses stack: /stacks/scheduler.yml

# Check health
curl http://localhost:8090/health

# View API docs
open http://localhost:8090/docs

API Authentication

All protected endpoints require an API key:

# Set in environment or use default
export SCHEDULER_API_KEY="your-api-key-here"

# Make authenticated request
curl -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  http://localhost:8090/tasks

Scheduling Tasks

Task Configuration

Tasks are defined with:

  • task_name: Unique identifier
  • service: Which service owns this task
  • executor: Python module to execute
  • priority: 1-100 (1=emergency, 10-30=user, 40-70=maintenance)
  • schedule: Minute, hour, day, month, day_of_week (-1 = any)
  • config: JSON configuration for executor

Scheduling Examples

# Every minute (wildcard)
minute=-1, hour=-1, day_of_month=-1, month=-1, day_of_week=-1

# Daily at 3:05 AM
minute=5, hour=3, day_of_month=-1, month=-1, day_of_week=-1

# 11th of every month at 4:00 AM
minute=0, hour=4, day_of_month=11, month=-1, day_of_week=-1

# Every Monday at 9:00 AM
minute=0, hour=9, day_of_month=-1, month=-1, day_of_week=0

# First day of January at midnight
minute=0, hour=0, day_of_month=1, month=1, day_of_week=-1

Priority System

Priority Range  Purpose           Examples
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1-5             Emergency/System  Critical system tasks
10-30           User Tasks        User-initiated operations
40-70           Maintenance       Backups, cleanup, doc sync
71-100          Low Priority      Optional background tasks

REST API

Task Management

# List all tasks
GET /tasks
GET /tasks?enabled=true&service=scheduler

# Get task details
GET /tasks/{task_name}

# Create new task
POST /tasks
{
  "task_name": "my_task",
  "service": "scheduler",
  "executor": "example_executor",
  "priority": 50,
  "minute": 0,
  "hour": 4,
  "description": "Daily task at 4 AM",
  "config": {"key": "value"}
}

# Update task
PUT /tasks/{task_name}
{
  "priority": 60,
  "enabled": false
}

# Delete task
DELETE /tasks/{task_name}

# Manually trigger task
POST /tasks/{task_name}/trigger

Execution History

# View recent executions
GET /executions?limit=20

# Filter by task
GET /executions?task_name=my_task&limit=10

# Filter by status
GET /executions?status=success

# Filter by service
GET /executions?service=scheduler

System Stats

# Get system statistics
GET /stats
{
  "scheduler_running": true,
  "tasks_enabled": 3,
  "tasks_currently_running": 0,
  "concurrent_limit": 5,
  "execution_stats_24h": {
    "success": 15,
    "failed": 1
  }
}

Task Executors

Executors are Python modules that implement the actual task logic.

Built-in Executors

1. Example Executor

File: src/executors/example_executor.py Purpose: Test/example implementation

config = {
    "message": "Hello World",
    "delay_seconds": 2
}

2. Doc Sync Executor

File: src/executors/doc_sync_executor.py Purpose: Mirror documentation from GitHub to Gitea

config = {
    "project": "fastapi",
    "upstream_repo": "https://github.com/tiangolo/fastapi.git",
    "docs_paths": ["/docs"],  # Empty = entire repo
    "gitea_repo": "library/docs-fastapi",
    "branch": "main"
}

Features:

  • Clones upstream repository
  • Filters to specific paths or mirrors entire repo
  • Pushes to Gitea with authentication
  • Creates date-tagged snapshots
  • Generates .SYNC_INFO.md with metadata

3. Config Backup Executor

File: src/executors/config_backup_executor.py Purpose: Backup Docker configs and data

config = {
    "sources": [
        {
            "path": "/data/docker-data",
            "name": "docker-data",
            "excludes": ["*/cache/*", "*.log"]
        }
    ],
    "backup_dir": "/backups/configs",
    "compress": true,
    "retention_days": 30
}

Creating Custom Executors

  1. Create file in src/executors/your_executor.py
  2. Implement async execute(config: dict, settings: Settings) -> str function
  3. Return success message or raise exception on failure
# src/executors/my_executor.py
async def execute(config: dict, settings: Settings) -> str:
    """
    Execute custom task.

    Args:
        config: Task configuration from database
        settings: Global scheduler settings

    Returns:
        Success message

    Raises:
        Exception: On task failure
    """
    # Your task logic here
    result = do_something(config.get('param'))

    return f"Task completed: {result}"
  1. Create task using API:
curl -X POST http://localhost:8090/tasks \
  -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "task_name": "my_custom_task",
    "service": "scheduler",
    "executor": "my_executor",
    "priority": 50,
    "minute": 0,
    "hour": 2,
    "config": {"param": "value"}
  }'

Current Tasks

Active Schedules

Task Priority Schedule Description
test_example_task 50 Every minute Test task (can be disabled)
backup_docker_configs_daily 20 Daily 03:05 Backup Docker configs
sync_fastapi_docs_monthly 60 11th @ 04:00 Sync FastAPI docs to Gitea
sync_ollama_docs_monthly 60 12th @ 04:00 Sync Ollama docs to Gitea

Managing Tasks

# Disable test task
curl -X PUT http://localhost:8090/tasks/test_example_task \
  -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

# View execution history
curl -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  http://localhost:8090/executions?limit=10

Database Schema

scheduled_tasks

Stores task definitions (templates for execution).

- id (serial)
- task_name (varchar, unique)
- service (varchar) - owner service
- executor (varchar) - executor module name
- priority (integer) - 1-100
- minute, hour, day_of_month, month, day_of_week (integer) - schedule
- enabled (boolean)
- description (text)
- config (jsonb) - executor configuration
- last_run, last_status, last_duration_seconds - tracking
- retry_count, max_retries, timeout_seconds - execution control
- created_at, updated_at, created_by - metadata

task_executions

Stores individual execution records (audit trail).

- id (serial)
- task_id (integer) - references scheduled_tasks
- task_name, service, executor, priority - snapshot
- status (varchar) - pending, running, success, failed, timeout
- triggered_by (varchar) - scheduler, manual, retry
- triggered_at, started_at, completed_at - timestamps
- duration_seconds (integer)
- output (text) - success message
- error (text) - error details
- retry_count (integer)
- metadata (jsonb)

Testing

Running Tests

# All tests with coverage
docker exec -w /app scheduler /venv/bin/pytest --cov=src --cov-report=term

# Only unit tests (fast, no database)
docker exec -w /app scheduler /venv/bin/pytest -m unit

# Only integration tests (with database)
docker exec -w /app scheduler /venv/bin/pytest -m integration

# Only API tests
docker exec -w /app scheduler /venv/bin/pytest -m api

# Only executor tests
docker exec -w /app scheduler /venv/bin/pytest -m executor

# Specific test file
docker exec -w /app scheduler /venv/bin/pytest tests/test_api.py -v

# With detailed output
docker exec -w /app scheduler /venv/bin/pytest -vv --tb=long

Test Coverage

Current Coverage: 80%

Module                          Coverage
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
config.py                       100% ✅
example_executor.py             100% ✅
main.py (API endpoints)          95% ✅
doc_sync_executor.py             78% ✅
executor.py (core logic)         71% ✅
config_backup_executor.py        50% 📈
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TOTAL                            80% 🎯

Test Database

Tests use a dedicated PostgreSQL database:

  • Database: test_scheduler
  • User: test_scheduler_user
  • Location: postgres-shared container

Tests automatically:

  • Clean database before each test
  • Insert test fixtures
  • Verify database state
  • Rollback changes after test

Development

Project Structure

scheduler/
├── src/
│   ├── config.py              # Pydantic settings
│   ├── main.py                # FastAPI app & endpoints
│   ├── executors/             # Task executors
│   │   ├── example_executor.py
│   │   ├── doc_sync_executor.py
│   │   └── config_backup_executor.py
│   └── tasks/
│       └── executor.py        # Task execution engine
├── tests/
│   ├── conftest.py            # Pytest fixtures
│   ├── test_api.py            # API tests
│   ├── test_*_executor.py     # Executor tests
│   └── test_database_integration.py
├── requirements.txt           # Python dependencies
├── pytest.ini                 # Test configuration
└── README.md                  # This file

Adding Dependencies

# Add to requirements.txt with version pinning
echo "new-package~=1.0.0" >> requirements.txt

# Rebuild venv in container
docker restart scheduler

Debugging

# View logs
docker logs scheduler --tail 100 -f

# Check scheduler status
curl http://localhost:8090/health

# View database tasks
docker exec postgres-shared psql -U scheduler_user -d scheduler \
  -c "SELECT task_name, enabled, priority, last_status FROM scheduled_tasks;"

# View execution history
docker exec postgres-shared psql -U scheduler_user -d scheduler \
  -c "SELECT task_name, status, duration_seconds, completed_at FROM task_executions ORDER BY id DESC LIMIT 10;"

Environment Variables

Required environment variables (set in stacks/scheduler.yml):

# Database
POSTGRES_HOST=postgres-shared
POSTGRES_PORT=5432
POSTGRES_DB=scheduler
POSTGRES_USER=scheduler_user
POSTGRES_PASSWORD=${SCHEDULER_DB_PASSWORD}

# API Security
SCHEDULER_API_KEY=${SCHEDULER_API_KEY}

# Gitea (for doc sync)
GITEA_URL=http://gitea:3000
GITEA_USER=librarian
GITEA_PASSWORD=${GITEA_PASSWORD}

# Redis (future use)
REDIS_HOST=redis-shared
REDIS_PORT=6379
REDIS_DB=3

Monitoring

Health Checks

# Container health
docker ps | grep scheduler

# API health
curl http://localhost:8090/health

# Scheduler running
curl http://localhost:8090/stats | jq '.scheduler_running'

Metrics

# System statistics
curl -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  http://localhost:8090/stats | jq

# Recent executions
curl -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  "http://localhost:8090/executions?limit=20" | jq

# Failed tasks in last 24h
curl -H "Authorization: Bearer $SCHEDULER_API_KEY" \
  "http://localhost:8090/executions?status=failed" | jq

Common Issues

Task not running?

  1. Check if task is enabled: GET /tasks/{name}
  2. Verify schedule matches current time
  3. Check execution history for errors: GET /executions?task_name={name}
  4. View scheduler logs: docker logs scheduler

Task timing out?

  • Increase timeout_seconds in task configuration
  • Check executor implementation for long-running operations
  • Consider breaking into smaller tasks

Database connection errors?

  • Verify postgres-shared container is running
  • Check database credentials in environment
  • Test connection: docker exec scheduler psql -h postgres-shared -U scheduler_user -d scheduler

API Reference

Full OpenAPI documentation available at: http://localhost:8090/docs

Response Codes

  • 200 - Success
  • 400 - Bad request (invalid data)
  • 401 - Missing API key
  • 403 - Invalid API key
  • 404 - Resource not found
  • 500 - Internal server error

Pagination

Use limit parameter for controlling result count:

GET /executions?limit=50  # Default: 20, Max: 100

Filtering

Most list endpoints support filtering:

GET /tasks?enabled=true&service=scheduler
GET /executions?task_name=my_task&status=success&limit=10

Security

  • API Key Authentication: Required for all protected endpoints
  • Network Isolation: Runs on docker-dataplane network
  • Database Credentials: Stored in environment variables
  • Gitea Tokens: Used instead of passwords for Git operations
  • Resource Limits: CPU and memory limits in docker-compose

Performance

  • Concurrent Execution: Max 5 tasks simultaneously
  • Minute-based Processing: Lightweight scheduler tick every minute
  • Priority Queue: Higher priority tasks execute first
  • Database Indexes: Optimized queries for task selection
  • Connection Pooling: Reuses database connections

License

Part of Portainer Core infrastructure.

Support

For issues or questions:

  1. Check logs: docker logs scheduler
  2. View health: curl http://localhost:8090/health
  3. Review execution history: GET /executions
  4. Check this README for common solutions
S
Description
Tower-of-joy scheduler api
Readme
500 KiB
2026-08-11 14:51:32 +02:00
Languages
Python 96.9%
Makefile 1.8%
Shell 1.1%
Dockerfile 0.2%