Skip to main content
Each runtime exposes two related (but different) runtime stores:
  • pending_event_queue: events accepted by the bus but not yet started by the runloop
  • event_history: events the bus knows about (pending, started, and completed until trimmed)

What each store is for

The key difference: queue is “what still needs to start”, history is “what this bus has seen”.

Retention config options

Event lifecycle: queue -> history -> trim

  1. Emit:
    • Event is accepted.
    • Event is added to event_history.
    • Event is enqueued into pending_event_queue.
  2. Runloop begins processing:
    • Event is removed from pending_event_queue.
    • Event stays in event_history while handlers run.
  3. Completion:
    • Event is marked completed.
    • Event may remain in event_history or be dropped based on retention settings.
  4. Trimming:
    • max_history_size and max_history_drop determine whether old history is removed or new emits are rejected.

Trimming behavior by mode

  • max_history_size = None/null: no automatic history limit.
  • max_history_size = 0: completed events are removed immediately; only pending/in-flight visibility remains.
  • max_history_size > 0 and max_history_drop = false: bus rejects new emits once history reaches the limit.
  • max_history_size > 0 and max_history_drop = true: bus trims oldest history entries (prefers completed first; can drop uncompleted entries under extreme pressure).
All runtimes follow this policy. Internally, trim timing is implementation-specific (eager vs amortized cleanup), but externally the semantics above are the contract to rely on.

Common configurations

Inspecting queue vs history at runtime