Concept explainer
Message failure and replay
Describes what happens when a message errors in transit, how orophin holds and replays it, and how staff see the outstanding queue.
A message crossing between a hospital system and Pensieve travels a network that stalls, drops and reconnects. orophin, the bridge that runs on the hospital network, holds every message in a durable local store, replays whatever a dropped link left outstanding, and surfaces the queue to staff in Westron.
Two acknowledgements
The bridge sends a local acknowledgement the moment a message is safely stored. Pensieve sends a separate confirmation once it has recorded the message. This page follows a message between those two points.
The delivery guarantee
The bridge accepts a message from a hospital system, writes it to its local store, and only then acknowledges the sender. That acknowledgement confirms the message is safe on the hospital network. It stands apart from the confirmation Pensieve returns once the message is recorded, so a sending analyser is released the moment its message is durable rather than waiting on the whole platform.
The bridge carries each message at least once, and Pensieve recognises a repeat, so the pair records each message effectively once. A message that arrives twice after a lost confirmation is matched by its stable identifier and acknowledged again, rather than recorded a second time.
The message lifecycle
Every message the bridge holds sits in one of four states. It enters the store waiting, moves onto the connection, and clears once Pensieve confirms the write. A delivery that errors returns to waiting for another attempt.
| State | What it means | What moves it on |
|---|---|---|
| Waiting | Stored on the bridge, ready to send | The bridge puts it on the connection |
| In transit | Sent, awaiting the platform's confirmation | A confirmation clears it, or an error returns it to waiting |
| Confirmed | Recorded by Pensieve | The bridge clears it after a short retention |
| Held for review | Set aside after repeated attempts | A member of staff resolves or re-sends it |
Error and retry
A delivery that returns an error, times out, or meets a dropped link reverts to waiting. The bridge raises the attempt count and schedules the next try on a backoff, so a struggling link is retried at widening intervals rather than hammered. A timeout is treated exactly as a disconnect for that message.
After a set number of attempts a message moves to held for review. It is set aside rather than discarded: a counter records the depth and an alert draws a member of staff to it.
Reconnect and replay
On reconnect the bridge re-establishes its authenticated connection and replays every message still waiting or in transit. A message that was in transit when the link dropped, its confirmation still outstanding, is sent again. Pensieve de-duplicates by the message's stable identifier, so the replay records each message once.
A long-lived connection is renewed on a schedule. That renewal is treated as an ordinary disconnect: the bridge reconnects, re-establishes the session, and replays what remains outstanding, so a routine renewal carries the same guarantee as a network blip.
The outstanding queue
While the connection is down, or before it is established, inbound messages accumulate in the local store as waiting. The store is the offline queue. It holds a bounded number of messages, and a message that has waited beyond its time limit moves to held for review, where the sending system can re-send it.
When the queue is full, the bridge declines a further message back to the sending system so that system retries, rather than dropping the message silently. On reconnect the bridge drains the backlog at a bounded rate, so a reconnection burst reaches Pensieve steadily rather than as a stampede.
The store survives a restart
If the bridge host is powered off with messages in transit, restarting it replays those messages, and Pensieve recognises any that already landed. A crash delays delivery rather than losing it.
The queue in Westron
Staff watch the outstanding queue in Westron. Each connection shows its waiting depth, and the held-for-review group lists the messages that reached their attempt limit, so an operator can resolve or re-send them.
Common confusions
Does a network outage lose messages?
The bridge holds each message in its local store until Pensieve confirms it, and replays what is outstanding on reconnect, so an outage delays delivery rather than losing it.
What happens if the same result arrives twice?
Pensieve matches a repeat by its stable identifier and acknowledges it again, so the result is recorded once.
Where does a message go after repeated errors?
It moves to held for review, where a counter and an alert bring it to a member of staff to resolve or re-send.
Read how a connection is watched day to day in monitoring a connection.