async fn poll_operator_claim(__arg0: State<AppState>) -> ResponseExpand description
POST /xrpc/bot.did.pollOperatorClaim
Asks this server to look for its operator’s claim sooner than its timer would. Urgency, never authority.
§Why this exists, and why it cannot be more than a hint
A server reaches ServerState::Claimed only
by observing a standing bot.did.operator record through its own poll.
Nothing here changes that: this method takes no body, reads no
credential, names no operator, and its entire effect is to wake a task
that was going to run anyway. A server that took anybody’s word for a
claim would be a server anybody could claim.
What it buys is the gap between an operator running didbot operate and
the next scheduled poll, which is otherwise minutes of staring at a page
that says unclaimed after the work is already done.
§Why it cannot be turned into a poll amplifier
The bound is on this server’s outbound rate, not on inbound requests:
crate::operator_poll::MIN_POLL_INTERVAL is a floor between two polls,
and every nudge arriving inside one window coalesces into the same single
poll. So an unbounded flood of nudges costs the operator’s PDS at most
one extra request per window — which is what the timer was already going
to spend — and costs this server a wake-up on a task that exists. A rate
limiter on this route would bound how many nudges are accepted while
still letting an accepted burst multiply outbound requests, which is the
wrong quantity to bound.
It answers 202 — accepted, nothing has happened yet, which is literally
true — with a Retry-After naming the floor, so a caller that wants to
nudge again knows when it could matter.