Skip to main content

request_within_notice

Function request_within_notice 

Source
pub fn request_within_notice(
    ctx: &ServiceContext,
    peer: &str,
    msg: &Message,
    secs: i64,
    notice: Option<&dyn Fn()>,
    keep: Option<&dyn Fn(u8)>,
) -> Result<Message, Error>
Expand description

A bounded request with a callback fired once if the wait drags on - and, with a callback, NOT the same machinery as request_within.

With notice set to None this IS request_within. With a callback it rides the SDK’s _qhint request, which reads its outcomes differently, so:

  • A request that never left is retried once, as in request_within, after reacquiring the peer by name; if it still cannot be sent the answer is Error::Unreachable. What differs is how the failed send is recognised: _qhint reports a failed send and a passed deadline as the same Timeout, but it reports the deadline only once it has passed, so a Timeout sooner than secs is the send that never left (as request_watched reads it). A deadline that passed is Error::OutcomeUnknown and is never re-sent. (Until 2026-10-16 there was no retry at all, and a peer that started after the caller could not be reached until something else reacquired it.)
  • A peer that died holding the request is Error::OutcomeUnknown, never Error::PeerDied: the wait is a timed receive, so no ReplyDead reaches it.

It also adds Error::Cancelled, for a person who pressed q - and it is not safe for a task that serves clients; see the module header.

§Why this exists, given the rest of this module is about not being clever

services/shell prints [q] quit when a network request lingers, so a person waiting on an unreachable host can stop it rather than wonder. That is an interactive affordance and it is exactly the sort of thing a standard library should NOT own - which is why the callback takes no arguments and returns nothing. It means only “you have been waiting a while”. What to do about it - print, poll a key, set a flag - stays entirely with the caller, and this module keeps knowing nothing about consoles.

Without it the shell cannot move onto this library without losing that affordance, which would have been a real regression dressed up as a migration.

keep, when given, receives every key the wait reads that is not a quit key, in order. A wait that watches for q has to read the console, and without it whatever the operator typed ahead is lost (backlog/fixed/80 H16).