OptionaldelayOptionalheadersAdd headers to the request, which the callee will be able to access using Request.headers.
OptionalidempotencyIdempotency key to use for this request.
OptionalinputOverride input serde.
Optional ExperimentallimitAn optional concurrency limit key within the scope. A limit key can only be used in conjunction with a scope (see Context.scope).
NOTE: This API is in preview and is not enabled by default.
To use it in restate-server 1.7, enable the flow control and protocol v7 experimental features,
via RESTATE_EXPERIMENTAL_ENABLE_PROTOCOL_V7=true and RESTATE_EXPERIMENTAL_ENABLE_VQUEUES=true.
These can be enabled only on new clusters, for more info check out https://docs.restate.dev/services/flow-control#enabling-flow-control.
When the experimental features are disabled, this method fails the invocation with a retryable error, causing the invocation to be retried until fixed.
The limit key enforces hierarchical concurrency limits on invocations sharing the same scope.
It can have one or two levels separated by / (e.g. "tenant1" or "tenant1/user42").
Each level must consist only of [a-zA-Z0-9_.-] characters, and 1 <= length <= 36.
The limit key is not part of the request identity: two calls to the same target with the same scope and object key but different limit keys refer to the same resource instance. The limit key only affects concurrency limits, not resource identity.
OptionalnameObservability name, recorded in the Restate journal.
Makes a type-safe one-way RPC to the specified target service, after a delay specified by the milliseconds' argument. This method is like setting up a fault-tolerant cron job that enqueues the message in a message queue. The handler calling this function does not have to stay active for the delay time.
Both the delay timer and the message are durably stored in Restate and guaranteed to be reliably delivered. The delivery happens no earlier than specified through the delay, but may happen later, if the target service is down, or backpressuring the system.
The delay message is journaled for durable execution and will thus not be duplicated when the handler is re-invoked for retries or after suspending.
This call will return immediately; the message sending happens asynchronously in the background. Despite that, the message is guaranteed to be sent, because the completion of the invocation that triggers the send (calls this function) happens logically after the sending. That means that any failure where the message does not reach Restate also cannot complete this invocation, and will hence recover this handler and (through the durable execution) recover the message to be sent.