Module event 

Events: R6/R7 as a wait-on-event-with-timeout

The second half of the time axis (Thor’s RTOS proposal): an R6/R7 submission is not fire-and-forget or poll — the requester blocks on the Result event up to its Deadline. Events are the primary trigger; timers are the backup for when no event arrives.

This module provides the types and the idempotency logic; the actual async blocking / dispatch surface is the hub’s (the implementing track). An Event carries a request_id so a Result can be matched to its Request and deduped — HUB’s caveat: a requester can time out, retry, then the slow-but-successful Result arrives; without request-id dedup you’d double-count it (once as a miss, once as a result). EventLog gives each request exactly one terminal accounting.

Structs

Event

An event on the web4 event axis — the primary trigger for R6/R7 acts.

EventLog

Idempotency ledger over request resolutions. Each request_id gets one terminal accounting: the first resolution (a fired event or a timeout) wins; any later one is a Admit::Duplicate. This is what stops a slow-but-successful Result arriving after a timeout from being counted both as a miss (trust debit) and a result.

WaitCondition

A wait-on-event-with-timeout: the submission blocks on an event matching topic + request_id, up to deadline. Timers are the backup trigger.

Enums

Admit

Whether a resolution is the first for its request, or a duplicate.

WaitOutcome

The result of a wait-on-event-with-timeout.