This example shows a familiar request/response workflow without adding a remote command API. Requests and responses are ordinary validated Lace records:
for_each porcelain;+Link targets the exact request hash;The policy in policy/request-response.interlang.tmpl
checks the configured client and service By values. Its
checked RecordLink relation requires a response to link to
a request that is present as a validated record. The caller’s
observation policy additionally selects the exact
+Link: request <request-hash> value.
This is a record convention, not generic RPC. It
does not promise remote execution, exactly-once handling, delivery
acknowledgement, cancellation, timeouts, one response, or
transport-command semantics. A durable service must define its own
replay/idempotency and lifecycle policy. The related request-response-records
scenario explores errors, multiple responses, replay/idempotency
records, and acknowledgements as explicit application records.
From the repository root:
cargo run --manifest-path examples/request-response-service/Cargo.toml
The generated record hashes vary because the example creates fresh client and service keys. Successful output has this shape:
request stored: yes
service observed exact request: yes
service published linked response: yes
caller observed exact response link: yes
response link: request <request-hash>
handler result: EXAMPLE REQUEST PAYLOAD
The program also asserts that:
+Link contains the exact request hash;list over the caller Lace returns exactly
that response.