scietex.service
Async worker framework for building background daemon services in Python.
Provides a hierarchy of workers — from basic signal-handling daemons to concurrent task processors with Valkey-backed distributed queues.
Python ≥ 3.10 · License: MIT
Documentation
- Overview — Core components and architecture
- BasicWorker — Signal handling, logging, heartbeat & watchdog managers
- TaskProcessor — Concurrent task processing, handler dispatch, timeout monitoring
- ValkeyWorker — Valkey stream-based task distribution
- Task Handler — Pluggable handler architecture, typed schemas
Installation
# Core package (no Valkey)
pip install scietex.service
# With Valkey (Redis-compatible) support
pip install "scietex.service[valkey]"
Dependencies: msgspec>=0.20.0, pyyaml>=6.0, scietex.logging>=2.0.0
Quick Start
Basic Async Worker
A minimal daemon with signal handling, heartbeat, and watchdog. See the full BasicWorker docs for lifecycle, manager system, and configuration details.
import asyncio
import logging
from scietex.service import BasicWorker, WorkerConfig
class MyWorker(BasicWorker):
async def heartbeat(self) -> None:
self.logger.info("Worker is alive")
async def watchdog(self) -> None:
self.logger.debug("Running watchdog checks")
async def cleanup(self) -> None:
self.logger.info("Shutting down gracefully")
async def main() -> None:
worker = MyWorker(
WorkerConfig(
service_name="my_service",
version="1.0.0",
logging_level=logging.DEBUG,
heartbeat_interval=10,
watchdog_interval=1,
)
)
await worker.start()
await worker.events["exit"].wait()
if __name__ == "__main__":
asyncio.run(main())
Send SIGINT (Ctrl+C) or SIGTERM to trigger graceful shutdown.
Task Processor
Register handlers for different task types and process them concurrently. See the full TaskProcessor docs for architecture, task processing flow, and best practices.
import asyncio
import logging
from scietex.service import TaskProcessor, TaskProcessorConfig
from scietex.service.task_handler import TaskData, TaskHandler, TaskResult
class EmailHandler(TaskHandler):
@property
def supported_tasks(self) -> list[str]:
return ["send_email"]
async def initialize(self) -> bool:
# Connect to email service, etc.
self.logger.info("Email handler initialized")
return True
async def handle(self, task_data: TaskData) -> TaskResult:
try:
# Process task_data.payload
self.logger.info("Sending email…")
return TaskResult(status="success", error="")
except Exception as exc:
return TaskResult(status="error", error=str(exc))
class MyProcessor(TaskProcessor):
async def fetch_tasks(self) -> bool:
# Pull tasks from your source (DB, API, queue, etc.)
# and enqueue them for processing:
# self.enqueue_task(task_id, task_data)
# Return True when at least one task was enqueued so the
# task_queue_manager drains a backlog back-to-back.
return False
async def main() -> None:
processor = MyProcessor(
TaskProcessorConfig(
service_name="email_worker",
version="1.0.0",
queue_size=100,
max_concurrent_tasks=5,
)
)
processor.add_task_handler(EmailHandler)
await processor.start()
await processor.events["exit"].wait()
if __name__ == "__main__":
asyncio.run(main())
Valkey Worker
Distributed task processing backed by a Valkey (Redis-compatible) stream. See the full ValkeyWorker docs for architecture, key naming, and configuration reference.
import asyncio
import logging
from scietex.service import (
ValkeyAdvancedConfig,
ValkeyBaseConfig,
ValkeyConfig,
ValkeyNode,
ValkeyWorker,
ValkeyWorkerConfig,
)
async def main() -> None:
config = ValkeyConfig(
base_config=ValkeyBaseConfig(
nodes=[ValkeyNode(host="localhost", port=6379)],
request_timeout=10_000,
),
advanced_config=ValkeyAdvancedConfig(
connection_timeout=10_000,
tcp_nodelay=True,
),
)
worker = ValkeyWorker(
ValkeyWorkerConfig(
service_name="distributed_worker",
version="1.0.0",
logging_level=logging.DEBUG,
heartbeat_interval=10,
valkey_config=config,
queue_size=100,
max_concurrent_tasks=10,
)
)
await worker.start()
await worker.events["exit"].wait()
if __name__ == "__main__":
asyncio.run(main())
Tasks are stored in a Valkey stream named
scietex:{service_name}:tasks and consumed via a consumer
group scietex:{service_name}:task_group.
Architecture
Worker Hierarchy
See BasicWorker, TaskProcessor, and ValkeyWorker for detailed architecture diagrams.
BasicWorker — Signal handling, async logging, heartbeat &
watchdog managers, graceful shutdown
└── TaskProcessor — Task queue, concurrent processing, handler
dispatch, timeout watchdog
└── ValkeyWorker — Valkey stream integration, connection
management, stream-based task fetching
Manager Lifecycle
Managers are async methods decorated with @Manager. The worker
discovers them via the class MRO and runs each as an asyncio.Task:
- Start — Manager loop runs the decorated method in a
while Trueloop until cancelled. - Error — On any exception (except
CancelledError), the error is recorded and the manager is automatically restarted, up tomanager_max_retriesconsecutive failures (default 5), after which the manager gives up and ends in the terminalFAILEDstate (observable viaworker.failed_managers; the watchdog logs CRITICAL but does not auto-shutdown). - Stop — On shutdown, managers are cancelled and their optional
cleanupcallbacks are invoked.
Task Handler System
See the Task Handler docs for the full handler lifecycle, schema details, and best practices.
- Register:
processor.add_task_handler(HandlerClass)— Registers a handler class under its class name. The processor creates a single handler instance on start. Dispatch is driven by the handler'ssupported_tasksdeclaration, not by a registration key. An optional keyword-onlyname(processor.add_task_handler(HandlerClass, name="...")) lets multiple instances of one class coexist under distinct keys. Arbitrary**handler_kwargsare also forwarded to the handler constructor on every instantiation, enabling stateful handlers — seeexamples/stateful_handler.py. - Declare support:
Handler.supported_tasksproperty must return a list of task type strings this handler can process. - Dispatch: When a task arrives, the processor calls
handler.supports(task_type)on each registered handler. The first handler returningTruereceives the task. - Initialize:
handler.start()callshandler.initialize()and setshandler.is_readyto the returned value, so it isTrueonly ifinitialize()returnedTrue. - Handle:
await handler.handle(task_data)returns aTaskResultwithstatus("success"/"error"), optionalerrormessage, and optionalpayload. - Timeout: Tasks exceeding their
timeout(default 3s) are canceled and either re-queued or discarded perTaskTimeout.timeout_action. - Cancel: A built-in
cancel_taskhandler cancels a running or queued task by id. A deliberate cancel writesstatus="cancelled"with the originalTaskDataembedded, so the caller can modify and resubmit it under a new task id.
Task Schemas
All schemas are frozen msgspec.Struct instances (immutable).
| Type | Description |
|---|---|
TaskData |
Immutable task payload: task (type string), payload (bytes), timeout (TaskTimeout), canceled_action ("requeue"/"discard") |
TaskResult |
Handler result: status ("success"/"error"), error (message), processed_at (UTC datetime), payload (bytes), plus error-taxonomy fields error_code, retryable, partial |
TaskTimeout |
Timeout config: timeout (seconds, None for default 3s), timeout_action ("requeue"/"discard") |
TaskStatus |
Per-task tracking record: task_id, service, task, status ("queued"/"running"/"completed"/"failed"/"cancelled"), progress, result, data (original TaskData embedded on a deliberate cancel), error, error_code, timestamps |
TaskTracker |
Internal runtime handle (in task_handler/runtime.py): tracks running asyncio.Task, associated TaskData, and monotonic start time |
TaskEnvelope |
Versioned transport envelope: version (int, 1) wrapping data (serialized TaskData bytes) — the durable on-the-wire format |
Configuration
Config Directory Precedence
The worker searches for a config directory in this order:
conf_dirargument (if provided and is a directory)SCIETEX_CONFIG_DIRenvironment variable$XDG_CONFIG_HOME/scietex/~/.config/scietex//etc/scietex//usr/local/etc/scietex/./config/(current working directory)~/.config/scietex/— created if none of the above exist
The first existing directory is used. If none exist, ~/.config/scietex/
is created.
Valkey Configuration
ValkeyWorker reads valkey.yml from the config directory:
base_config:
nodes:
- host: localhost
port: 6379
user_credentials: null
use_tls: false
request_timeout: 5000
database_id: null
client_name: null
inflight_requests_limit: null
client_az: null
lazy_connect: null
read_from: PRIMARY
backoff_strategy: null
protocol: RESP3
advanced_config:
connection_timeout: 10000
tcp_nodelay: null
tls_config:
use_insecure_tls: false
root_pem_cacerts: null
If the file is missing, it is created with default values. If the file is
present but invalid, a RuntimeError is raised and the file is left
untouched. The read (and the default-file write) is deferred to the first
connect()/initialize() call — constructing ValkeyWorker() with no
explicit valkey_config does not touch the filesystem (AR-066).
API Reference
Exported from scietex.service
| Symbol | Description |
|---|---|
BasicWorker |
Base async daemon worker |
TaskProcessor |
Concurrent task processor |
Manager |
Decorator for creating managed async loop methods |
ValkeyWorker |
Valkey-backed distributed worker |
WorkerConfig |
Immutable msgspec.Struct configuration for BasicWorker |
TaskProcessorConfig |
Immutable configuration for TaskProcessor (extends WorkerConfig) |
ValkeyWorkerConfig |
Immutable configuration for ValkeyWorker (extends TaskProcessorConfig) |
__version__ |
Package version string |
The Valkey configuration classes (ValkeyConfig, ValkeyNode,
ValkeyUserCredentials, ValkeyBackoffStrategy, ValkeyBaseConfig,
ValkeyAdvancedConfig, ValkeyTlsAdvancedConfiguration, ValkeyWorkerConfig)
are top-level
re-exports: they are importable directly from scietex.service (as in the
Valkey quick-start above), not only from scietex.service.valkey.
Exported from scietex.service.task_handler
| Symbol | Description |
|---|---|
TaskHandler |
Abstract base class for task handlers |
TaskHandlerContext |
Narrow read-only context passed to handlers (service name, instance id, logger) |
CancelTaskHandler |
Built-in handler for the cancel_task task type |
CancelTaskRequest |
Payload schema for a cancel_task task (target_task_id, reason) |
CancelTaskResponse |
Success payload schema for a cancel_task task (target_task_id, outcome) |
CancelOutcome |
Cancellation outcome literal (cancelled/not_running/ignored/not_found) |
CancelReason |
Why a task was cancelled (deliberate/timeout/shutdown) |
CANCEL_TASK_TYPE |
Task type string that selects the built-in cancel handler ("cancel_task") |
TaskData |
Task payload schema |
TaskResult |
Task result schema |
TaskTimeout |
Timeout configuration schema |
TaskStatus |
Per-task tracking record schema |
TaskProgress |
Granular progress payload embedded in TaskStatus.progress (progress, value) |
TaskTracker |
Internal runtime handle for running tasks (not a wire schema) |
TaskEnvelope |
Versioned transport envelope (version + serialized payload bytes) |
encode_task_envelope |
Wrap a TaskData in a versioned envelope and msgpack-encode it |
decode_task_envelope |
Decode an envelope back to a TaskData (returns None on invalid/unknown version) |
Exported from scietex.service.valkey
| Symbol | Description |
|---|---|
ValkeyConfig |
Top-level Valkey configuration |
ValkeyBaseConfig |
Basic connection settings |
ValkeyAdvancedConfig |
Advanced connection settings |
ValkeyNode |
Server node address |
ValkeyUserCredentials |
Authentication credentials |
ValkeyBackoffStrategy |
Reconnection backoff config |
ValkeyTlsAdvancedConfiguration |
TLS settings |
ValkeyWorkerConfig |
Immutable configuration for ValkeyWorker (extends TaskProcessorConfig) |
purge_task_stream |
Standalone operational utility to purge a task stream |
Development
Setup
# Clone the repository and install all dependencies
uv sync --all-extras
# Or install specific extras
uv sync --extra dev --extra test --extra lint
Commands
| Command | Description |
|---|---|
uv run ruff check src/ |
Lint (auto-fix: ruff check --fix) |
uv run ty check src/ |
Type check |
uv run ruff format src/ |
Format code |
uv run pytest tests/ |
Run tests |
tox |
Run tests with coverage |
Running Examples
The examples/ directory contains runnable blueprints; see
examples/README.md for what each demonstrates.
python -m examples.basic_worker
python -m examples.manager_cleanup
python -m examples.manager_collision
python -m examples.task_processor
python -m examples.named_task_handlers
python -m examples.stateful_handler
python -m examples.valkey_async_service # requires valkey-glide
python -m examples.valkey_pubsub_worker # requires valkey-glide
python -m examples.valkey_perf # requires valkey-glide
python -m examples.progress_and_cancel # requires valkey-glide
License
MIT
Release files for scietex.service 4.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| scietex_service-4.1.0.tar.gz | 74.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| scietex_service-4.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 142.9 kB
Release files / scietex_service-4.1.0.tar.gz
| Download URL | scietex_service-4.1.0.tar.gz |
|---|---|
| Size | 74.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0410a1d2076be52037607e0d660268c078a2f4f05c895044f753be580fc682dc
|
|
BLAKE2b-256 checksum How to use checksums |
2877e46dda2f8f4888dd099c84e225b50e97007f6ff126829b04582a251ac1d6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 16, 2026.
Transparency logRelease files / scietex_service-4.1.0-py3-none-any.whl
| Download URL | scietex_service-4.1.0-py3-none-any.whl |
|---|---|
| Size | 68.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
3e31e7b01d22e2e9ae89531e2aedeebce2ffc91034a13eb3b8851be7e2f4e1a2
|
|
BLAKE2b-256 checksum How to use checksums |
e2bdf861448888b214462fb1f7269c07cabbc7e711542cac43e19322396fe307
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 16, 2026.
Transparency log