Skip to main content

Publisher Example

This page provides comprehensive examples of publishing events to OmniDaemon, from simple one-liners to advanced patterns with all features.

Overview

What This Guide Covers:
  • ✅ Simple publishing (minimal code)
  • ✅ Full publishing (all parameters)
  • ✅ Batch publishing (multiple events)
  • ✅ Webhook callbacks
  • ✅ Reply-to patterns (agent-to-agent)
  • ✅ Correlation and causation tracking
  • ✅ Multi-tenancy with tenant_id
  • ✅ Custom source tracking
  • ✅ Result retrieval (24h TTL)

Prerequisites

1. Install OmniDaemon

2. Set Up Event Bus

3. Set Up Environment

4. Start an Agent Runner

You need an agent listening on the topic you publish to:

Simple Publishing (Minimal)

Example 1: Simplest Possible

Output:
What Happens:
  1. Event published to omni-stream:greet.user
  2. Any agent subscribed to greet.user receives it
  3. Task ID returned immediately (async processing)

Full Publishing (All Parameters)

Example 2: Using All Features

Output:

Parameter Explanations

Required Parameters

topic (Required)

What: The topic (channel) to publish to Format: {domain}.{action} (convention) Example:
How it works:
  • Creates/uses stream: omni-stream:{topic}
  • Delivered to all agents subscribed to this topic

payload.content (Required)

What: Your actual data Format: Any JSON-serializable dict Example:

Optional Parameters

payload.webhook (Optional)

What: HTTP URL to POST result to when processing completes When to use: When you want push notifications instead of polling TTL: Results stored for 24 hours Example:
What gets POSTed:
Use cases:
  • ✅ Real-time notifications
  • ✅ Integration with external systems
  • ✅ Async job completion callbacks
  • ✅ Monitoring/alerting systems
Implementation tip:

payload.reply_to (Optional)

What: Topic to publish result to (agent-to-agent communication) When to use: When building agent pipelines/workflows Example:
What happens:
  1. Agent processes event
  2. Result published to reply_to topic
  3. Another agent (listening to that topic) receives it
  4. Creates event chains!
Agent chain example:
Use cases:
  • ✅ Multi-stage pipelines
  • ✅ Agent orchestration
  • ✅ Workflow automation
  • ✅ Fan-out/fan-in patterns

correlation_id (Optional)

What: Track a single request across multiple events Format: String (UUID recommended) Lifetime: Passed through entire event chain Example:
Use cases:
  • ✅ Distributed tracing
  • ✅ Log aggregation
  • ✅ Debug workflows
  • ✅ Track user journeys
Usage in callback:

causation_id (Optional)

What: Track cause-effect relationships in event chains Format: String (usually the ID of the triggering event) Difference from correlation_id: Shows parent-child relationships Example:
Use cases:
  • ✅ Event sourcing
  • ✅ Causality tracking
  • ✅ Root cause analysis
  • ✅ Event replay

source (Optional)

What: Identifies where the event originated Format: String (system/service name) Example:
Use cases:
  • ✅ Multi-source systems
  • ✅ Source-specific logic
  • ✅ Analytics
  • ✅ Security auditing
Usage in callback:

tenant_id (Optional)

What: Isolate data by customer/organization Format: String (customer identifier) Lifetime: Passed through entire event chain Example:
Use cases:
  • ✅ Multi-tenancy
  • ✅ Customer isolation
  • ✅ Per-customer processing
  • ✅ Billing/usage tracking
Usage in callback:

Result Storage & Retrieval

24-Hour TTL

Results are stored for 24 hours by default:
Why 24 hours?
  • ✅ Balance availability with storage efficiency
  • ✅ Most use cases retrieve results quickly
  • ✅ Prevents unbounded storage growth
  • ✅ Encourages proper result handling
Custom TTL (advanced):

Retrieving Results


Common Patterns

Pattern 1: Fire-and-Forget

Pattern 2: Wait for Result

Pattern 3: Batch Publishing

Pattern 4: Webhook Callback

Pattern 5: Agent Pipeline

Pattern 6: Multi-Tenant Publishing


Complete Example

File: publisher.py (based on actual example)
Run it:
Output:

Best Practices

1. Always Use correlation_id

2. Structure Your Topics

3. Use Webhooks for Long Tasks

4. Propagate IDs Through Chains

5. Handle Expiration Gracefully


Troubleshooting

Event Not Processed

Result Not Found

Webhook Not Called


Further Reading


Summary

Required Parameters:
  • topic - Where to send event
  • payload.content - Your data
Optional Parameters:
  • payload.webhook - HTTP callback URL
  • payload.reply_to - Agent-to-agent topic
  • correlation_id - Track across events
  • causation_id - Track cause-effect
  • source - Event origin
  • tenant_id - Multi-tenancy
Result Storage:
  • 24-hour TTL by default
  • Retrieve with sdk.get_result(task_id)
  • Or use webhook for push notifications
  • Or use reply_to for agent chains
Best Practices:
  • Always use correlation_id
  • Structure topics hierarchically
  • Use webhooks for long tasks
  • Propagate IDs through chains
  • Handle expiration gracefully
Publishing events to OmniDaemon is simple yet powerful! 🚀