Service Invocation And Idempotency

Service A needs Service B's result before continuing. The integrator calls B over raw HTTP (fetch) instead of ctx.call, losing durability of the call.

Invoke B with ctx.call(...) so the call and its result are journaled: on A's replay the result is reused, and the call participates in Restate's durability and tracing. A raw fetch is a non-durable side effect that re-executes on replay unless wrapped in ctx.run, and loses cross-service durable lin…

Service A must trigger B but not wait for B's result. The integrator uses ctx.call and awaits it anyway, coupling A's latency to B.

Use a one-way send (ctx.send) for fire-and-forget: Restate durably enqueues the invocation to B and returns immediately, so A does not block on B and B still runs durably exactly-once. Reserve ctx.call (awaited) for when A genuinely needs B's result. Sends are still durable — not lost on crash.

An external client calls a Restate service through the ingress and retries on timeout without setting an idempotency key, risking a duplicate invocation.

Set the idempotency key (the documented Restate idempotency key header / option) on the ingress invocation so a client retry dedupes to the original invocation and returns its result rather than starting a second run. Derive the key from the business request id. Within its retention window the key …