gRPC Explorer
The gRPC explorer (sidebar → Explore, /grpc) lists every gRPC RPC the fleet's Wolverine services expose that forwards to the message bus — one row per service · method, across every monitored service at once.
It is the gRPC sibling of the HTTP explorer. The two answer the same question about different front doors: what can call into this system from outside, and what does it set in motion when it does?
What appears here, and what does not
Rows come from each service's captured grpcEndpoints — Wolverine's own gRPC endpoint descriptors. That means the explorer lists the RPCs Wolverine maps onto the bus, not every method on every .proto service you host. An RPC that is implemented as an ordinary gRPC method with no Wolverine forwarding never reaches the bus, so CritterWatch has nothing to say about it and does not list it.
A service that maps no Wolverine.Grpc surface therefore shows no rows — correctly. The empty state says so rather than implying the fleet has no gRPC at all.
How to read the table
| Column | What it is |
|---|---|
| Service (app) | The monitored service hosting the RPC — the same identity as everywhere else in the console |
| gRPC Service | The gRPC service name from the contract (the .proto service, not the app) |
| Method | The RPC method name |
| Kind | The stream kind — Unary, ServerStreaming, or BidirectionalStreaming |
| Forwards message | The Wolverine message this RPC puts on the bus. This is the link between the gRPC surface and everything else the console knows |
| Response | The response type, or none for a fire-and-forget RPC |
| Dispatched by | The stub / contract interface whose generated wrapper does the dispatching. A service identity, not a message |
Narrow the list with the stream-kind facet or the search box; the facet is URL-bound, so /grpc?kinds=Unary lands pre-filtered — symmetric with the HTTP explorer's ?sources=. The global service selector scopes the table like every other page.
Sorting ranks the whole set rather than the page on screen, and the grid discloses what it withheld beneath the table.
The per-RPC detail page
Click a row to open /service/:serviceId/grpc/:grpcService/:methodName. It carries three things:
- Overview — the stream kind, the forwarded message, the response, and the dispatching stub. On a BidirectionalStreaming RPC the forwarded message is annotated "one per inbound stream item", because that RPC forwards each item of the inbound stream individually: the request type is the per-item element type, not the stream wrapper. The difference between "one message" and "one message per item" is the difference between a quiet endpoint and a firehose.
- Configuration — the captured per-RPC properties, rendered the same way as everywhere else in the console.
- Cause & Effect — the focused subgraph of what calling this RPC actually sets in motion, on the same substrate as the Workflow screen. It is keyed on the forwarded Wolverine message, never on the gRPC stub, exactly as the HTTP chain detail page keys on its chain's request type. Clicking a node navigates out to the handler, message-type, or projection detail page.
That last card is the reason the explorer earns its place: every RPC listed here forwards its request to the bus, so the request type is a Wolverine message, and the whole of the console's static knowledge — handlers, subscriptions, projections — applies to it.
Related screens
- The same RPCs also appear in the HTTP explorer with a Grpc source chip, because they are ASP.NET Core endpoints too. This page is the gRPC-shaped view of them.
- Workflow shows the static shape a message can flow through; Conversations shows what actually happened to one concrete call.