Prosody: Ruby Bindings for Kafka

Prosody offers Ruby bindings to the Prosody Kafka client, providing features for message production and consumption, including configurable retry mechanisms, failure handling strategies, and integrated OpenTelemetry support for distributed tracing.

Features

• Kafka Consumer: Per-key ordering with cross-key concurrency, offset management, consumer groups
• Kafka Producer: Idempotent delivery with configurable retries
• Timer System: Persistent scheduled execution backed by Cassandra or in-memory store
• Keyed State: Per-key value/map/deque collections that survive across events, transactional by default
• Quality of Service: Fair scheduling limits concurrency and prevents failures from starving fresh traffic. Pipeline mode adds deferred retry and monopolization detection
• Distributed Tracing: OpenTelemetry integration for tracing message flow across services
• Backpressure: Pauses partitions when handlers fall behind
• Mocking: In-memory Kafka broker for tests (mock: true)
• Failure Handling: Pipeline (retry forever), Low-Latency (dead letter), Best-Effort (log and skip)

Installation

Add this line to your application's Gemfile:

gem "prosody"

Or install directly:

gem install prosody

The gem ships RBS signatures for the public API. Prosody::EventHandler[Payload] carries an application payload type into Prosody::Message[Payload], and keyed- state definitions carry their item types through context.state. A bare handler, message, definition, or state handle defaults to Prosody::json_value. See the typed examples for Ruby and companion RBS files checked by Steep.

Quick Start

require "prosody"

# Initialize the client with Kafka bootstrap server, consumer group, and topics
client = Prosody::Client.new(
  # Bootstrap servers should normally be set using the PROSODY_BOOTSTRAP_SERVERS environment variable
  bootstrap_servers: "localhost:9092",

  # To allow loopbacks, the source_system must be different from the group_id.
  # Normally, the source_system would be left unspecified, which would default to the group_id.
  source_system: "my-application-source",

  # The group_id should be set to the name of your application
  group_id: "my-application",

  # Topics the client should subscribe to
  subscribed_topics: "my-topic"
)

# Define a custom message handler
class MyHandler < Prosody::EventHandler
  def on_message(context, message)
    # Process the received message
    puts "Received message: #{message.payload.inspect}"

    # Schedule a timer for delayed processing (requires Cassandra unless mock: true)
    if message.payload["schedule_followup"]
      future_time = Time.now + 30 # 30 seconds from now
      context.schedule(future_time)
    end
  end

  def on_timer(context, timer)
    # Handle timer firing
    puts "Timer fired for key: #{timer.key} at #{timer.time}"
  end
end

# Subscribe to messages using the custom handler
client.subscribe(MyHandler.new)

# Send a message to a topic
client.send_message("my-topic", "message-key", {"content" => "Hello, Kafka!"})

# Ensure proper shutdown when done
client.unsubscribe

Architecture

Prosody enables efficient, parallel processing of Kafka messages while maintaining order for messages with the same key:

• Partition-Level Parallelism: Separate management of each Kafka partition
• Key-Based Queuing: Ordered processing for each key within a partition
• Concurrent Processing: Simultaneous processing of different keys
• Backpressure Management: Pause consumption from backed-up partitions

Quality of Service

All modes use fair scheduling to limit concurrency and distribute execution time. Pipeline mode adds deferred retry and monopolization detection.

Fair Scheduling (All Modes)

The scheduler controls which message runs next and how many run concurrently.

Virtual Time (VT): Each key accumulates VT equal to its handler execution time. The scheduler picks the key with the lowest VT. A key that runs for 500ms accumulates 500ms of VT; a key that hasn't run recently has zero VT and gets priority.

Two-Class Split: Normal messages and failure retries have separate VT pools. The scheduler allocates execution time between them (default: 70% normal, 30% failure). During a failure spike, retries get at most 30% of execution time—fresh messages continue processing.

Starvation Prevention: Tasks receive a quadratic priority boost based on wait time. A task waiting 2 minutes (configurable) gets maximum boost, overriding VT disadvantage.

Deferred Retry (Pipeline Mode)

Moves failing keys to timer-based retry so the partition can continue processing other keys.

On transient failure: store the message offset in Cassandra, schedule a timer, return success. The partition advances. When the timer fires, reload the message from Kafka and retry.

# Configure defer behavior
client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  defer_enabled: true,           # Enable deferral (default: true)
  defer_base: 1.0,               # Wait 1s before first retry
  defer_max_delay: 86400.0,      # Cap at 24 hours
  defer_failure_threshold: 0.9   # Disable when >90% failing
)

Failure Rate Gating: When >90% of recent messages fail, deferral disables. The retry middleware blocks the partition, applying backpressure upstream.

Monopolization Detection (Pipeline Mode)

Rejects keys that consume too much execution time.

The middleware tracks per-key execution time in 5-minute rolling windows. Keys exceeding 90% of window time are rejected with a transient error, routing them through defer.

# Configure monopolization detection
client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  monopolization_enabled: true,     # Enable detection (default: true)
  monopolization_threshold: 0.9,    # Reject keys using >90% of window
  monopolization_window: 300.0      # 5-minute window
)

Handler Timeout

Handlers are automatically cancelled if they exceed a deadline:

client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  timeout: 30.0,             # Cancel after 30 seconds
  stall_threshold: 60.0      # Report unhealthy after 60 seconds
)

When a handler times out, context.should_cancel? returns true. The handler should exit promptly. If not specified, timeout defaults to 80% of stall_threshold.

Configuration

For the complete configuration reference, see CONFIGURATION.md.

Constructor options take precedence. Unset options use environment variables, then library defaults.

Logging

Prosody exposes a module-level logger used by both the native Rust extension and the Ruby async processor. By default it writes to $stdout at the INFO level.

# Read the current logger
Prosody.logger
# => #<Logger:... @level=1 ...>

# Assign a custom logger
Prosody.logger = Logger.new("log/prosody.log", level: Logger::DEBUG)

# Or silence logging entirely
Prosody.logger = Logger.new(File::NULL)

Set Prosody.logger before creating a Prosody::Client. The Rust runtime reads the logger on first client initialization and will use whatever logger is configured at that point.

Setting the logger back to nil restores the default:

Prosody.logger = nil
Prosody.logger.level  # => Logger::INFO

Liveness and Readiness Probes

Prosody includes a built-in probe server for consumer-based applications that provides health check endpoints. The probe server is tied to the consumer's lifecycle and offers two main endpoints:

1. /readyz: A readiness probe that checks if any partitions are assigned to the consumer. Returns a success status only when the consumer has at least one partition assigned, indicating it's ready to process messages.

2. /livez: A liveness probe that checks if any partitions have stalled (haven't processed a message within a configured time threshold).

Configure the probe server using either the client constructor:

client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  probe_port: 8000,        # Set to false to disable
  stall_threshold: 15.0    # Seconds before considering a partition stalled
)

Or via environment variables:

PROSODY_PROBE_PORT=8000  # Set to 'none' to disable
PROSODY_STALL_THRESHOLD=15s  # Default stall detection threshold

Important Notes

1. The probe server starts automatically when the consumer is subscribed and stops when unsubscribed.
2. A partition is considered "stalled" if it hasn't processed a message within the stall_threshold duration.
3. The stall threshold should be set based on your application's message processing latency and expected message frequency.
4. Setting the threshold too low might cause false positives, while setting it too high could delay detection of actual issues.
5. The probe server is only active when consuming messages (not for producer-only usage).

Note

Rails users: Because prosody-rb is built on the async gem, handlers run on fibers rather than threads. Rails defaults ActiveSupport's isolation level to :thread, which causes ActiveRecord connections to be shared across fibers and produces errors like:

ActiveRecord::StatementInvalid: Mysql2::Error: This connection is in use by: #<Fiber

Set the isolation level to :fiber in config/application.rb:

config.active_support.isolation_level = :fiber

Client Stall State

You can monitor the stall state programmatically using the client's methods:

# Get the number of partitions currently assigned to this consumer
partition_count = client.assigned_partitions

# Check if the consumer has stalled partitions
if client.is_stalled?
  warn 'Consumer has stalled partitions'
end

Advanced Usage

Pipeline Mode

Pipeline mode is the default mode. Ensures ordered processing, retrying failed operations indefinitely:

# Initialize client in pipeline mode
client = Prosody::Client.new(
  mode: :pipeline,  # Explicitly set pipeline mode (this is the default)
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic"
)

Low-Latency Mode

Prioritizes quick processing, sending persistently failing messages to a failure topic:

# Initialize client in low-latency mode
client = Prosody::Client.new(
  mode: :low_latency,  # Set low-latency mode
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  failure_topic: "failed-messages"  # Specify a topic for failed messages
)

Best-Effort Mode

Optimized for development environments or services where message processing failures are acceptable:

# Initialize client in best-effort mode
client = Prosody::Client.new(
  mode: :best_effort,  # Set best-effort mode
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic"
)

Event Type Filtering

Prosody supports filtering messages based on event type prefixes, allowing your consumer to process only specific types of events:

# Process only events with types starting with "user." or "account."
client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  allowed_events: ["user.", "account."]
)

Or via environment variables:

PROSODY_ALLOWED_EVENTS=user.,account.

Matching Behavior

Prefixes must match exactly from the start of the event type:

Matches:

• {"type": "user.created"} matches prefix user.
• {"type": "account.deleted"} matches prefix account.

No Match:

• {"type": "admin.user.created"} doesn't match user.
• {"type": "my.account.deleted"} doesn't match account.
• {"type": "notification"} doesn't match any prefix

If no prefixes are configured, all messages are processed. Messages without a type field are always processed.

Source System Deduplication

Prosody prevents processing loops in distributed systems by tracking the source of each message:

# Consumer and producer in one application
client = Prosody::Client.new(
  group_id: "my-service",
  source_system: "my-service-producer",  # Must differ from group_id to allow loopbacks; defaults to group_id
  subscribed_topics: "my-topic"
)

Or via environment variable:

PROSODY_SOURCE_SYSTEM=my-service-producer

How It Works

1. Producers add a source-system header to all outgoing messages.
2. Consumers check this header on incoming messages.
3. If a message's source system matches the consumer's group ID, the message is skipped.

This prevents endless loops where a service consumes its own produced messages.

Message Deduplication

Prosody automatically deduplicates messages using the id field in their JSON payload. Consecutive messages with the same ID and key are processed only once.

The deduplication system uses:

• A global in-memory cache shared across all partitions, surviving partition reassignments within a process
• A Cassandra-backed persistent store for cross-restart deduplication

# Messages with IDs are deduplicated per key
client.send_message("my-topic", "key1", {
  "id" => "msg-123",      # Message will be processed
  "content" => "Hello!"
})

client.send_message("my-topic", "key1", {
  "id" => "msg-123",      # Message will be skipped (duplicate)
  "content" => "Hello again!"
})

client.send_message("my-topic", "key2", {
  "id" => "msg-123",      # Message will be processed (different key)
  "content" => "Hello!"
})

Consumer deduplication is mandatory — it is the commit oracle that makes keyed state correct — so it cannot be disabled. idempotence_cache_size must be at least 1; setting it to 0 in the client configuration raises an ArgumentError:

client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  idempotence_cache_size: 0  # Rejected: consumer deduplication cannot be disabled
)

This applies to every client — Prosody::Client.new always builds a consumer, so 0 is rejected regardless of whether any topics are subscribed, and whether it is supplied in the client configuration or via PROSODY_IDEMPOTENCE_CACHE_SIZE.

To invalidate all previously recorded dedup entries (e.g. after a data migration), change the version string:

client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  idempotence_version: "2"  # Changing this invalidates all existing dedup records
)

The idempotence_ttl option controls how long dedup records are retained in Cassandra (default: 7 days):

client = Prosody::Client.new(
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic",
  idempotence_ttl: 86400.0  # Keep dedup records for 1 day
)

Note that the in-memory cache is best-effort. Duplicates can still occur across different process instances.

Keyed State

Keyed state gives every Kafka key its own durable working memory. Prosody automatically uses the current message or timer key, so a handler can relate the current event to earlier events for that key. State survives restarts and rebalances. By default, changes become visible only when the event succeeds.

Use keyed state for time-aware stream processing: counters, deduplication, rolling aggregates, pending work, and per-key workflows. Keep your relational database as the source of truth for business data and for work that needs joins or ad hoc queries. Reconstructing stream state with repeated database queries can be slow and expensive; keyed state is built for that job.

Most collections should have a TTL. Set it comfortably beyond the longest timer or workflow that uses the state; Prosody validates the minimum supported TTL. Omit it only when keeping inactive keys forever is intentional.

Published state

Published state lets another client read a JSON value, map, or deque without subscribing to the owner's topics. Use the same definition for the owned collection and its read-only view. The owner sets published: true, names its subsystem, and registers the definition as usual:

CURRENT_ORDER = Prosody.value("current-order", published: true)

owner = Prosody::Client.new(
  group_id: "order-writer",
  subsystem: "checkout",
  state_collections: [CURRENT_ORDER]
)

# Inside the owner's handler, the event supplies the user key.
current_order = context.state(CURRENT_ORDER)
current_order.set({"sku" => "book"})

Another client opens a reader by naming the subsystem and passing that same definition. The reader is independent of subscriptions and only returns committed state:

order_reader = client.state("checkout", CURRENT_ORDER)
current_order = order_reader.get("customer-123")

Published readers provide the owned collection's read operations without its mutations. An owned handle gets the user key from the current event; a published reader is outside a handler, so every operation takes that key explicitly. Map and deque traversal returns an Enumerator when no block is given and reads in chunks rather than loading the entire collection. Use reverse_each_pair, reverse_each_key, reverse_each_value, or reverse_each for reverse traversal.

The default cache window is five seconds unless the client configuration changes it. Set read_cache: on a definition to choose a different freshness window, or read_cache: false to read durable storage on every operation. To stop publishing a collection, deploy its definition with published: false while keeping it registered and retaining subsystem for that deployment.

A counter for each key

Declare each collection once, register it on the client, and ask the event context for the current key's state:

COUNTER = Prosody.value("counter", ttl: 30 * 24 * 60 * 60)

class CountHandler < Prosody::EventHandler
  def on_message(context, _message)
    count = context.state(COUNTER)
    count.set((count.get || 0) + 1)
  end
end

client = Prosody::Client.new(
  group_id: "counters",
  subscribed_topics: "events",
  state_collections: [COUNTER]
)

Here, counters expire after 30 days without an update.

Window activity into one notification

This example turns a burst of activity into two useful notifications. It sends the first event immediately, collects later events for five minutes, then sends one summary. Because the user ID is the Kafka key, every user gets an independent window.

WINDOW = Prosody.value("window", ttl: 24 * 60 * 60)
PENDING = Prosody.message_deque("pending", capacity: 100, ttl: 24 * 60 * 60)

class ActivityHandler < Prosody::EventHandler
  def on_message(context, message)
    window = context.state(WINDOW)
    pending = context.state(PENDING)

    if window.get
      pending.push(message)
      return
    end

    notify(message.key, [message])
    window.set(true)
    context.clear_and_schedule(Time.now + 5 * 60)
  end

  def on_timer(context, timer)
    pending = context.state(PENDING)
    batch = []
    pending.each { |message| batch << message }

    notify(timer.key, batch) unless batch.empty?
    pending.clear
    context.state(WINDOW).clear
  end
end

See the complete, Steep-checked example for signatures, client setup, and notify: examples/keyed_state_windowing.rb and examples/keyed_state_windowing.rbs.

Why this works:

• Register both definitions in state_collections before subscribing. Keyed state uses Cassandra unless mock: true.
• Use clear_and_schedule, not schedule, so a retried event does not add another timer for the same key.
• capacity: 100 and the one-day TTL prevent an inactive or unusually busy key from retaining an unlimited backlog. Since this example only appends, overflow drops the oldest saved message.
• A message_deque requires the original Kafka messages to remain available for the whole window. Use a plain deque of payloads if topic retention or compaction cannot guarantee that.
• Prosody runs one handler at a time for each key, so a user's message and timer handlers cannot overlap.
• Sending a notification is outside Prosody's state transaction and may happen again after a retry. Give notifications a stable idempotency key, or send them through an outbox, when duplicates matter.

Collections and handles

A definition gives a collection a stable name, kind, and options. Register it once on the client, then pass the same definition to context.state to access the current key. Do not reuse a persisted name for a different collection kind or payload type.

Create handles inside the handler and do not retain them or their iterators afterward. State operations look synchronous but yield the current fiber while Prosody performs the work.

Collection	JSON payload	Kafka message	Main operations
Value	Prosody.value	Prosody.message_value	get, set, clear
Ordered string map	Prosody.map	Prosody.message_map	get, get_many, key?, set, delete, each_pair, each_key, clear
Deque	Prosody.deque	Prosody.message_deque	push, unshift, pop, shift, get, length, each, clear

Map and deque scans return enumerators when called without a block. Map keys are strings. nil means absence and cannot be stored—use clear or delete instead.

When changes become visible

Reads inside a handler see its earlier writes. The default behavior is the safest choice for most handlers: Prosody buffers those changes and publishes them together when the event succeeds. If the handler raises, none of its pending changes become visible.

Each collection also offers explicit controls for workflows that need different behavior:

• read_uncommitted: true writes that collection's changes after the handler succeeds but before the event is recorded as complete. A crash in between can leave the changes visible even though the event is retried. Use it only for idempotent changes, where processing the same event again produces the same stored result.
• commit immediately publishes this collection's pending changes. They remain visible even if the handler later raises and the event is retried.
• rollback discards this collection's pending changes since its last commit. It cannot undo changes that were already committed.

Timer Functionality

Prosody supports timer-based delayed execution within message handlers. When a timer fires, your handler's on_timer method will be called:

class MyHandler < Prosody::EventHandler
  def on_message(context, message)
    # Schedule a timer to fire in 30 seconds
    future_time = Time.now + 30
    context.schedule(future_time)

    # Schedule multiple timers
    one_minute = Time.now + 60
    two_minutes = Time.now + 120
    context.schedule(one_minute)
    context.schedule(two_minutes)

    # Check what's scheduled
    scheduled_times = context.scheduled
    puts "Scheduled timers: #{scheduled_times.length}"
  end

  def on_timer(context, timer)
    puts "Timer fired!"
    puts "Key: #{timer.key}"
    puts "Scheduled time: #{timer.time}"
  end
end

Timer Methods

The context provides timer scheduling methods that allow you to delay execution or implement timeout behavior:

• schedule(time): Schedules a timer to fire at the specified time
• clear_and_schedule(time): Clears all timers and schedules a new one
• unschedule(time): Removes a timer scheduled for the specified time
• clear_scheduled: Removes all scheduled timers
• scheduled: Returns an array of all scheduled timer times

Timer Object

When a timer fires, the on_timer method receives a timer object with these properties:

• key (String): The entity key identifying what this timer belongs to
• time (Time): The time when this timer was scheduled to fire

Note: Timer precision is limited to seconds due to the underlying storage format. Sub-second precision in scheduled times will be rounded to the nearest second.

Timer Configuration

Timer functionality requires Cassandra for persistence unless running in mock mode. Configure Cassandra connection via environment variable:

PROSODY_CASSANDRA_NODES=localhost:9042  # Required for timer persistence

Or programmatically when creating the client:

client = Prosody::Client.new(
  bootstrap_servers: "localhost:9092",
  group_id: "my-application",
  subscribed_topics: "my-topic",
  cassandra_nodes: "localhost:9042"  # Required unless mock: true
)

For testing, you can use mock mode to avoid Cassandra dependency:

# Mock mode for testing (timers work but aren't persisted)
client = Prosody::Client.new(
  bootstrap_servers: "localhost:9092",
  group_id: "my-application",
  subscribed_topics: "my-topic",
  mock: true  # No Cassandra required in mock mode
)

OpenTelemetry Tracing

Prosody supports OpenTelemetry tracing, allowing you to monitor and analyze the performance of your Kafka-based applications. The library will emit traces using the OTLP protocol if the OTEL_EXPORTER_OTLP_ENDPOINT environment variable is defined.

Note: Prosody emits its own traces separately because it uses its own tracing runtime, as it would be expensive to send all traces to Ruby.

Required Gems

To use OpenTelemetry tracing with Prosody, you need to install the following gems:

gem 'opentelemetry-sdk', '~> 1.10'
gem 'opentelemetry-api', '~> 1.7'
gem 'opentelemetry-exporter-otlp', '~> 0.31'

Initializing Tracing

To initialize tracing in your application:

require 'opentelemetry/sdk'
require 'opentelemetry/exporter/otlp'

OpenTelemetry::SDK.configure do |c|
  c.service_name = 'my-service-name'
  c.add_span_processor(
    OpenTelemetry::SDK::Trace::Export::BatchSpanProcessor.new(
      OpenTelemetry::Exporter::OTLP::Exporter.new
    )
  )
end

tracer = OpenTelemetry.tracer_provider.tracer('my-service-name')

Setting OpenTelemetry Environment Variables

Set the following standard OpenTelemetry environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_SERVICE_NAME=my-service-name

For more information on these and other OpenTelemetry environment variables, refer to the OpenTelemetry specification.

Using Tracing in Your Application

After initializing tracing, you can define spans in your application, and they will be properly propagated through Kafka:

class MyHandler < Prosody::EventHandler
  def initialize
    @tracer = OpenTelemetry.tracer_provider.tracer('my-service-name')
  end

  def on_message(context, message)
    @tracer.in_span('process-message') do |span|
      # Process the received message
      span.add_event('message.received', attributes: {
        'message.payload' => message.payload.to_json
      })
    end
  end
end

Span Linking

By default, message execution spans use child (child-of relationship — the execution span is part of the same trace as the producer). Timer execution spans use follows_from (the execution span starts a new trace with a span link back to the scheduling span, since timer execution is causally related but not part of the same operation).

Both strategies are configurable via the message_spans / PROSODY_MESSAGE_SPANS and timer_spans / PROSODY_TIMER_SPANS options. Accepted values: 'child', 'follows_from'.

Best Practices

Ensuring Thread-Safe Handlers

Your event handler methods will be called concurrently. Avoid using mutable shared state across event handler calls. If you must use shared state, use appropriate synchronization primitives.

Ensuring Idempotent Message Handlers

Idempotent message handlers are crucial for maintaining data consistency, fault tolerance, and scalability when working with distributed, event-based systems. They ensure that processing a message multiple times has the same effect as processing it once, which is essential for recovering from failures.

Strategies for achieving idempotence:

1. Natural Idempotence: Use inherently idempotent operations (e.g., setting a value in a key-value store).

2. Deduplication with Unique Identifiers:

   • Kafka messages can be uniquely identified by their partition and offset.
   • Before processing, check if the message has been handled before.
   • Store processed message identifiers with an appropriate TTL.

3. Database Upserts: Use upsert operations for database writes (e.g., INSERT ... ON CONFLICT DO UPDATE in PostgreSQL).

4. Partition Offset Tracking:

   • Store the latest processed offset for each partition.
   • Only process messages with higher offsets than the last processed one.
   • Critically, store these offsets transactionally with other state updates to ensure consistency.

5. Idempotency Keys for External APIs: Utilize idempotency keys when supported by external APIs.

6. Check-then-Act Pattern:

   • For non-idempotent external systems, verify if an operation was previously completed before execution.
   • Maintain a record of completed operations, keyed by a unique message identifier.

7. Saga Pattern:

   • Implement a state machine in your database for multi-step operations.
   • Each message advances the state machine, allowing for idempotent processing and easy failure recovery.
   • Particularly useful for complex, distributed transactions across multiple services.

Proper Shutdown

Always unsubscribe from topics before exiting your application:

# Ensure proper shutdown
client.unsubscribe

This ensures:

1. Completion and commitment of all in-flight work
2. Quick rebalancing, allowing other consumers to take over partitions
3. Proper release of resources

Implement shutdown handling in your application using signal handlers:

require "prosody"

client = Prosody::Client.new(
  bootstrap_servers: "localhost:9092",
  group_id: "my-consumer-group",
  subscribed_topics: "my-topic"
)

# Set up a shutdown queue
shutdown = Queue.new

# Configure signal handlers to trigger shutdown
Signal.trap("INT") { shutdown.push(nil) }
Signal.trap("TERM") { shutdown.push(nil) }

# Subscribe to messages
client.subscribe(MyHandler.new)

# Block until a signal is received
shutdown.pop # This blocks until something is pushed to the queue by a signal handler

# Clean shutdown
puts "Shutting down gracefully..."
client.unsubscribe

Error Handling

Prosody classifies errors as transient (temporary, can be retried) or permanent (won't be resolved by retrying). By default, all errors are considered transient.

Use the Prosody::EventHandler error classification methods:

class MyHandler < Prosody::EventHandler
  # Mark TypeErrors and NoMethodErrors as permanent (not retryable)
  permanent :on_message, TypeError, NoMethodError

  # Mark JSON::ParserError as transient (retryable)
  transient :on_message, JSON::ParserError

  def on_message(context, message)
    # Your message handling logic here
    # TypeError and NoMethodError will be treated as permanent
    # JSON::ParserError will be treated as transient
    # All other exceptions will be treated as transient (default behavior)
  end
end

Best practices:

• Use permanent errors for issues like malformed data or business logic violations.
• Use transient errors for temporary issues like network problems.
• Be cautious with permanent errors as they prevent retries and can result in data loss.
• Consider system reliability and data consistency when classifying errors.

Handling Task Cancellation

Prosody cancels tasks during partition rebalancing, timeout, or shutdown. During shutdown, handlers run freely for most of the shutdown_timeout before the cancellation signal fires—giving in-flight work time to complete. When cancelled, your handler receives Async::Stop at the next yield point (I/O operation, sleep, etc.).

Best practices:

1. Use ensure blocks for resource cleanup—they run even when Async::Stop is raised.
2. For CPU-bound loops that don't yield, check context.should_cancel? periodically.
3. Exit promptly when cancelled to avoid rebalancing delays.

class MyHandler < Prosody::EventHandler
  def on_message(context, message)
    resource = acquire_resource
    begin
      items = message.payload["items"]
      items.each do |item|
        # For CPU-bound work, check cancellation periodically
        return if context.should_cancel?

        process_item(item)
      end
    ensure
      # Always runs, even on Async::Stop
      release_resource(resource)
    end
  end
end

If you catch Async::Stop and don't re-raise it, Prosody considers the task successful:

def on_message(context, message)
  do_work
rescue Async::Stop
  # Custom cleanup on cancellation
  cleanup
  raise  # Re-raise to signal cancellation to Prosody
end

Failing to handle cancellation properly can lead to resource leaks or delayed rebalancing.

Release Process

Prosody uses an automated release process managed by GitHub Actions. Here's an overview of how releases are handled:

1. Trigger: The release process is triggered automatically on pushes to the main branch.

2. Release Please: The process starts with the "Release Please" action, which:

   • Analyzes commit messages since the last release.
   • Creates or updates a release pull request with changelog updates and version bumps.
   • When the PR is merged, it creates a GitHub release and a git tag.

3. Build Process: If a new release is created, the following build jobs are triggered:

   • Linux builds for x86_64 and aarch64 architectures.
   • Linux musl builds for the same architectures.
   • macOS builds for x86_64 and arm64 architectures.
   • Windows builds for x64 architecture.

4. Artifact Upload: Each build job uploads its artifacts (Ruby native extensions) to GitHub Actions.

5. Publication: If all builds are successful, the final step publishes the built gems.

Contributing to Releases

To contribute to a release:

1. Make your changes in a feature branch.
2. Use Conventional Commits syntax for your commit messages. This helps Release Please determine the next version number and generate the changelog.
3. Create a pull request to merge your changes into the main branch.
4. Once your PR is approved and merged, Release Please will include your changes in the next release PR.

Manual Releases

While the process is automated, manual intervention may sometimes be necessary:

• You can manually trigger the release workflow from the GitHub Actions tab if needed.
• If you need to make changes to the release PR created by Release Please, you can do so before merging it.

Ensure you have thoroughly tested your changes before merging to main.

API Reference

Prosody::Client

• new(**config): Initialize a new Prosody client with the given configuration.
• send_message(String topic, String key, Prosody::json_value payload): Send a JSON-serializable message.
• consumer_state: Get the current state of the consumer (:unconfigured, :configured, or :running).
• source_system: Get the source system identifier configured for the client.
• state(subsystem, definition): Open a typed, read-only published value, map, or deque.
• subscribe: [Payload] (Prosody::EventHandler[Payload]) -> void: Subscribe while preserving the handler's payload specialization.
• unsubscribe: Unsubscribe from messages and shut down the consumer.
• assigned_partitions: Get the number of partitions currently assigned to this consumer.
• is_stalled?: Check if the consumer has stalled partitions.

Prosody::EventHandler

A base class for user-defined handlers. Its RBS payload parameter flows into Message#payload; a bare handler defaults to Prosody::json_value.

class MyHandler < Prosody::EventHandler
  # Optional error classification
  permanent :on_message, TypeError
  transient :on_message, JSON::ParserError

  def on_message(context, message)
    # Implement your message handling logic here
  end

  def on_timer(context, timer)
    # Implement your timer handling logic here
  end
end

Prosody::Message

Prosody::Message[Payload] represents a Kafka message. Payload defaults to Prosody::json_value (nil, booleans, numbers, strings, arrays, and string-keyed hashes, recursively). The parameter is static documentation and does not perform runtime validation.

For a type-safe handler, describe the JSON record and specialize the handler in your application's RBS:

type order_event = { "order_id" => String, "total" => Integer }

class OrderHandler < Prosody::EventHandler[order_event]
  def on_message: (Prosody::Context, Prosody::Message[order_event]) -> void
end

Ruby can then use message.payload["order_id"] as a String and message.payload["total"] as an Integer. See examples/keyed_state.rb and its companion examples/keyed_state.rbs for payload typing that also flows through message-backed state.

Messages have the following attributes:

• topic (String): The name of the topic.
• partition (Integer): The partition number.
• offset (Integer): The message offset within the partition.
• timestamp (Time): The timestamp when the message was created or sent.
• key (String): The message key.
• payload (Payload): The JSON-deserialized message payload.

Prosody::Context

Represents the context of message processing:

• should_cancel?: Check if cancellation has been requested (includes timeout and shutdown).
• on_cancel: Blocks until cancellation is signaled.
• state(definition): Binds a registered collection for the current event attempt, returning a typed handle (ValueState, MapState, or DequeState). Raises PermanentStateError when the name was never registered, or when the definition's kind/payload disagrees with the collection's durably-registered schema. See the Keyed State API reference below.

Timer scheduling methods:

• schedule(time): Schedules a timer to fire at the specified time
• clear_and_schedule(time): Clears all timers and schedules a new one
• unschedule(time): Removes a timer scheduled for the specified time
• clear_scheduled: Removes all scheduled timers
• scheduled: Returns an array of all scheduled timer times

Prosody::Timer

Represents a timer that has fired, provided to the on_timer method:

• key (String): The entity key identifying what this timer belongs to
• time (Time): The time when this timer was scheduled to fire

Keyed State

Definition constructors (each returns a frozen definition object used both in Configuration#state_collections and with context.state):

• Prosody.value(name, ttl: nil, read_uncommitted: nil, published: nil, read_cache: nil)
• Prosody.map(name, ttl: nil, keyset_limit: nil, read_uncommitted: nil, published: nil, read_cache: nil)
• Prosody.deque(name, ttl: nil, capacity: nil, read_uncommitted: nil, published: nil, read_cache: nil)
• Prosody.message_value(name, ttl: nil, read_uncommitted: nil)
• Prosody.message_map(name, ttl: nil, keyset_limit: nil, read_uncommitted: nil)
• Prosody.message_deque(name, ttl: nil, capacity: nil, read_uncommitted: nil)

Published readers take the user key as their first argument. Prosody::PublishedValue provides get. Prosody::PublishedMap provides get, get_many, key?, each_pair, each_key, each_value, and their reverse variants. Prosody::PublishedDeque provides get, length/size, empty?, first, last, each, and reverse_each. Traversal methods return an Enumerator when no block is given.

Prosody::ValueState:

• get, set(value), clear, commit, rollback

Prosody::MapState (keys are String):

• get(key), get_many(keys), set(key, value), delete(key) (returns nil), clear
• key?, each_pair, each_key, and each_value (each with reverse traversal), commit, rollback

Prosody::DequeState:

• push(value), unshift(value), pop, shift, length (aliased size), empty?, get(index), clear
• each / reverse_each (block or Enumerator), commit, rollback

Errors:

• Prosody::TransientStateError < Prosody::TransientError: the default — a temporary store read/write failure, or any caller mistake (a nil/unrepresentable write, item-shape mismatch, out-of-range index, invalid scan direction), rejected transient so it retries rather than discarding the message.
• Prosody::PermanentStateError < Prosody::PermanentError: reserved for failures a retry cannot resolve in-process (unregistered/identity-mismatched collection, duplicate registration, bad TTL), or one a handler raises explicitly.
• Prosody::NullValueError < Prosody::TransientStateError: raised when a nil is written; use clear/delete instead.

State errors are never Terminal (core folds Terminal into Transient).