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:

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.

2.8 KiB Raw Blame History