Three terminals, bottom-up:
dotnet run —project src/Samples/OrderChainWithGrpc/InventoryServer dotnet run —project src/Samples/OrderChainWithGrpc/OrderServer dotnet run —project src/Samples/OrderChainWithGrpc/OrderClient
The client's success path prints the reservation plus the correlation-id seen on both hops; the
failure path prints the `NotFound` surfaced by the upstream server.
### Compared to grpc-dotnet examples
There's no direct equivalent in the grpc-dotnet repo — the official examples assume users
hand-write client interceptors for anything they want stamped on outgoing calls, and none of the
shipped examples chain one service's handler into another service's RPC. The Wolverine sample
collapses that entire surface area into a single registration line, because ambient context and
typed-exception symmetry are *the* things the `AddWolverineGrpcClient<T>()` extension exists to
provide.
## Related
* [Index](./) — overview + getting started.
* [How gRPC Handlers Work](./handlers) — why the samples can keep their service classes tiny.
* [Code-First and Proto-First Contracts](./contracts) — pick the style each sample uses.
* [Streaming](./streaming) — the streaming shapes two of these samples implement.
* [Error Handling](./errors) — the pipeline `GreeterWithGrpcErrors` exercises end-to-end.
* [Typed gRPC Clients](./client) — full reference for the `AddWolverineGrpcClient<T>()` extension
`OrderChainWithGrpc` demonstrates.
---
---
url: /guide/messaging/transports/azureservicebus/scheduled.md
---