retry-rendezvous

Retry rendezvous

Retry rendezvous ensures that a repeated request reaches the completion record needed to recognize its earlier execution.

Migration: RIFL associates a completion record with a designated object; both must move together. The receiving server rebuilds the request lookup before serving retries. [1]

Result: A duplicate returns the saved result, not a new result inferred from the object's current value. [1]

Example: Hesela's constructed five-case illustration distinguishes missing history, an unrestored lookup, a substituted reply, delayed admission and restored history; it is not a deployed-system measurement. [2]

Relations

related
Retry deduplication, Idempotency, Incarnation identifier

Citations

  1. Lee et al. Implementing Linearizability at Large Scale and Low Latency. SOSP 2015. DOI 10.1145/2815400.2815416; sections 3, 4.1 and 4.4. (accessed 2026-11-10)
  2. Hesela: retry rendezvous, constructed event-order model (accessed 2026-11-11)

Further reading

  1. Storage timeouts: retry state must travel with the data (accessed 2026-11-11)
Sources & caveats
  • Primary-source synthesis and an explicitly hypothetical model. No implementation or performance replication.

JSON: /data/terms/retry-rendezvous.json

Published by Hesela team · Updated

Report a correction · Editorial standards · Reuse guidance

Cite this page
Hesela team. Retry rendezvous. Hesela. 2026-11-11. https://hesela.dev/terms/retry-rendezvous/