Temporal Orchestration
39 workflow functions and 238 activities across 33 task queues. The important structural
fact is that almost all of it is one shared pipeline — provider-specific code is a
thin adapter at the front.
The layering
Activities import @cona/core/domains/* 292 times. The most-imported domain is actors
(21) — confirming that mutation attribution is enforced at the activity layer, not left to
core.
The shared ingestion pipeline
syncIntegrationWorkflow is the universal entry point for every integration. Its own
docstring calls it “a universal workflow that can process ANY integration using the
adapter pattern” (sync/sync-integration-workflow.ts:1-9).
This is why every integration worker registers 20-35 near-identical activities. The
adapter contributes steps 1 and the data fetch; steps 1.5 through 7 are shared by all
providers.
The pipeline ends by enqueuing to accounting_work_queue rather than calling accounting
directly. That decoupling is the subject of
Accounting Engine.
Provider-specific escapes
Three steps branch on provider inside the shared pipeline:
chunk-processor.ts labels two consecutive blocks STEP 5.5 (lines 370 and 409). A cosmetic
duplication in the source comments, not a logic error — recorded so a reader comparing this
diagram to the file is not confused.
Task queue routing
33 queue constants in packages/temporal-config/src/shared.ts. 29 have a live worker.
Four declared constants have no worker and no caller: amazon-orders, paypal-global,
shopify-global, and queue (TASK_QUEUE_NAME). Only shopify-global is marked deprecated in
the source. A workflow started on any of them would wait forever. They are omitted from the table
above.
Two-tier scheduling
shops-global runs a lightweight parent that fans work out to per-shop children:
The parent worker restricts workflowsPath to scheduled/ so it cannot accidentally pick
up heavy import workflows (workers/shopify.ts).
The Mirakl factory
Six marketplaces share one worker template — createMiraklMarketplaceWorker in
workers/mirakl.ts:76-189, instantiated once per queue with 29 activities each. The same
factory pattern repeats in the webapp action layer. See
Integrations.
Workflows by group
Activity groups
238 activities across 28 groups. The distribution is uneven:
datev at 44 is the largest single group — nearly a fifth of all activities.
Notes
Workflows must stay deterministic. Activity calls go through proxyActivities;
the workflow itself performs no I/O. syncIntegrationWorkflow uses continueAsNew for
long paginated syncs (api-mode-sync.ts:770,1040).
Adapters are imported from their files, never the barrel. adapters/registry.ts:6-9
warns that importing from ./index.js creates a circular dependency.
A versioning patch is in flight. sync-integration-workflow.ts:26 declares
LIVE_BACKGROUND_ACTIVITY_PATCH_ID — a Temporal patch gate for the live background
activity feed.
