The rest of steps 2 and 3 of docs/spec/features/relay.md, apart from
inbuxa:RelayMessage ("The link service", RL-T23):
- A new trace event category, relay, ids 650 to 658, with schema
labels and explanations: relay.session, relay.message-accepted,
relay.message-refused, relay.message-expired (warning),
relay.joined, relay.recipients-replaced, relay.event for any other
type the relay reports, relay.link-down (warning) and relay.link-up.
Each names the relay by its id and public hostname.
- The link service asks for RelayEvent push too. The linked node with
the lowest id (by the link records, fresh within three minutes) reads
the relay's events, emits them as relay.* events, and acknowledges
them, so the relay forgets them (RL-22). Events wait on the relay
until one node takes them, so none is lost while no node is linked.
- RL-T23: a node with no link to a joined relay for an hour raises
relay.link-down once, with the last error, and relay.link-up when the
link is back. Both reach the log, webhooks and OpenTelemetry. A relay
that never joined holds no mail and raises nothing.
- inbuxa:RelayMessage moves to step 5, with inbuxa-admin's Relays page,
once Outbound exists to show beside Inbound (spec status updated).
- The relayed message's judging and ingest futures are boxed (clippy
large_futures).
- The link system test checks the relay recorded the held message's
event while the link was off, and that every event was acknowledged
once it was back. Unit test for the alert's timing.
jcoffey-dev