Lace examples

Request/response records with an actual service handler

This example shows a familiar request/response workflow without adding a remote command API. Requests and responses are ordinary validated Lace records:

  1. the caller creates and stores a marked request;
  2. one open interlace converges it to the service Lace;
  3. the service observes the admitted request through public for_each porcelain;
  4. a deterministic handler creates and stores a service-marked response whose +Link targets the exact request hash;
  5. the same open interlace converges that response; and
  6. the caller observes and lists the exact linked response.

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.

Run

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: