generated from coulomb/repo-seed
100 lines
2.8 KiB
Markdown
100 lines
2.8 KiB
Markdown
# Temporal Conventions
|
|
|
|
## Namespace
|
|
|
|
| Environment | Namespace |
|
|
|---|---|
|
|
| Dev (Docker Compose) | `default` |
|
|
| Production | `activity-core-prod` |
|
|
|
|
Use the `default` namespace for all dev and test work. The production namespace is
|
|
created via the Temporal admin API as part of the Kubernetes deployment (EP-custodian,
|
|
extension point `af654abb`).
|
|
|
|
---
|
|
|
|
## Task Queues
|
|
|
|
| Queue name | Registered workers |
|
|
|---|---|
|
|
| `orchestrator-tq` | `RunActivityWorkflow` and all its activities (`load_activity_definition`, `resolve_context`, `log_run`) |
|
|
| `task-execution-tq` | `TaskExecutorWorkflow` compatibility stub only; real execution belongs in per-repo workers |
|
|
|
|
**Rule:** a workflow and its activities must be registered on the same task queue.
|
|
Cross-queue activity calls require an explicit `task_queue` argument on
|
|
`workflow.execute_activity()`.
|
|
|
|
---
|
|
|
|
## Workflow ID conventions
|
|
|
|
See `docs/idempotency.md` for the full workflow ID strategy.
|
|
|
|
Summary:
|
|
- `RunActivityWorkflow`: `activity-{activity_id}:{trigger_key}`
|
|
- `TaskExecutorWorkflow`: `task-{run_id}:{task_type}:{index}`
|
|
- Temporal Schedules: `activity-schedule-{activity_id}`
|
|
|
|
---
|
|
|
|
## Schedule ID conventions
|
|
|
|
Temporal Schedules are identified by `schedule_id`. The convention:
|
|
|
|
```
|
|
activity-schedule-{activity_definition.id}
|
|
```
|
|
|
|
This makes it trivial to look up the schedule for a given ActivityDefinition
|
|
without a separate mapping table.
|
|
|
|
---
|
|
|
|
## Worker registration
|
|
|
|
Each worker process registers:
|
|
- **Workflows**: `worker.register_workflow(WorkflowClass)`
|
|
- **Activities**: `worker.register_activity(activity_function)`
|
|
|
|
A single process may run workers for multiple task queues, but each `Worker`
|
|
instance is bound to one task queue. Use separate `Worker` instances for
|
|
`orchestrator-tq` and `task-execution-tq`.
|
|
|
|
`TaskExecutorWorkflow` is not a production execution surface for activity-core.
|
|
It exists only as a compatibility/idempotency stub that writes a synthetic
|
|
`task_instances` row in older tests and dev flows. Do not add concrete task
|
|
execution logic here; execution ownership belongs to per-repo workers or a
|
|
future execution-owned repo/workplan.
|
|
|
|
---
|
|
|
|
## Search attributes
|
|
|
|
`RunActivityWorkflow` sets the following search attributes (requires Elasticsearch
|
|
visibility, enabled in the dev docker-compose):
|
|
|
|
| Attribute | Type | Value |
|
|
|---|---|---|
|
|
| `ActivityId` | `Keyword` | The `ActivityDefinition.id` UUID |
|
|
| `ActivityName` | `Keyword` | The `ActivityDefinition.name` |
|
|
|
|
These allow filtering workflow runs by activity in the Temporal UI.
|
|
|
|
---
|
|
|
|
## Retry policy defaults
|
|
|
|
Unless overridden, all activities use:
|
|
|
|
```python
|
|
RetryPolicy(
|
|
initial_interval=timedelta(seconds=1),
|
|
backoff_coefficient=2.0,
|
|
maximum_interval=timedelta(minutes=5),
|
|
maximum_attempts=10,
|
|
)
|
|
```
|
|
|
|
Long-running context-resolution activities that call external services should set
|
|
`heartbeat_timeout` to detect stalls.
|