tatara-export-worker 0.2.172

Runs one declared ExportSpec from an ephemeral Process — reads the artifact, ships through the chosen VectorChannel, emits a typed export receipt
docs.rs failed to build tatara-export-worker-0.2.172
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.

Pure decision logic for tatara-export-worker — the binary that ships one declared ExportSpec from an ephemeral Process to its Vector-native channel.

The compounding move: every function in this module is pure (no HTTP, no NATS, no kube client, no clock), takes its inputs by reference, and returns a typed value the I/O layer in main.rs then consumes. That means the whole worker is unit-testable without standing up infrastructure — and any new artifact source or channel can be added by extending this module first, then the I/O glue mechanically follows.

Three substrate primitives live here:

  1. [prepare_event_payload] — given an [ArtifactVariant] + raw artifact bytes + run id + signal_type, produces the JSON event the channel will ship. Encoded once, shared by all channels.

  2. [resolve_run_id] / [resolve_subject] — string-template substitution for {{run_id}} in NATS subjects + event labels. Single source of truth so the worker, the reconciler, and any downstream cohort-correlation logic agree on what the run id means.

  3. [compose_export_receipt] — builds a typed ReceiptEnvelope of the export action itself, with the three BLAKE3 pillars derived from the ExportSpec (intent), the shipped payload bytes (artifact), and the outcome (control). The receipt chains into the Process's attestation tree, so the act of exporting is itself attested.

The I/O glue in main.rs is thin — argv → ExportSpec → call these functions → ship to channel → write receipt.