Feature / discussion — gRPC endpoint discovery surface for event-model origin
CritterWatch builds an event-model cause-and-effect graph: for each message-publishing origin (Wolverine handler, HTTP endpoint, scheduled job, …) it discovers which messages that origin publishes and renders a chain detail page. The JasperFx.Events PublisherKind enum already reserves GrpcEndpoint, but nothing populates it — there is no first-class way to discover a gRPC service method as a Wolverine message-publishing origin.
For HTTP this works because WolverineFx.Http chains expose endpoints as discoverable origins that the JasperFx.Events source generator can analyze for IMessageBus/InvokeAsync/PublishAsync calls and emit publisher origin (route + method). gRPC has no equivalent surface: a Grpc.AspNetCore service method that calls into Wolverine to publish a message is invisible to the generator, so PublisherKind.GrpcEndpoint stays unpopulated and a gRPC chain detail page has no data.
The ask
A first-class gRPC endpoint discovery surface — a convention/attribute (and the generator support to read it) that lets a gRPC service method be recognized as a Wolverine message-publishing origin, emitting PublisherKind.GrpcEndpoint with route/method origin (service + method, proto-derived metadata where reachable) — analogous to how HTTP endpoints are discovered today.
Open design question (why this is filed as discussion)
It is genuinely unclear whether this belongs in Wolverine at all. gRPC services are ASP.NET-owned; Wolverine has no gRPC integration package today, and the CritterWatch lifecycle-assembler work (#396 Phase 2, "B3") already flagged gRPC as "likely N/A, deferring unless a convention emerges." Two plausible shapes:
- A Wolverine.Grpc convention/integration that surfaces gRPC methods as message origins (parallels
WolverineFx.Http). Heavyweight; only worth it if gRPC-as-message-entrypoint is a pattern Wolverine wants to bless.
- N/A in Wolverine — gRPC stays an ASP.NET concern, and any cause-and-effect for it is derived purely from CritterWatch-side ASP.NET endpoint metadata (which already classifies gRPC for the HTTP Explorer via
GrpcMethodMetadata), without a PublisherKind.GrpcEndpoint event-model origin.
This issue exists to make that decision explicitly rather than leaving PublisherKind.GrpcEndpoint reserved-but-dead.
Downstream (CritterWatch)
- CritterWatch#499 — gRPC chain detail page (the event-model cross-reference view), hard-blocked on this surface.
- CritterWatch#618 — gRPC as a first-class source in the HTTP Explorer (the ASP.NET-metadata path that already works for display; this issue is about the event-model origin it can't yet show).
post-1.0 on the CritterWatch side.
Feature / discussion — gRPC endpoint discovery surface for event-model origin
CritterWatch builds an event-model cause-and-effect graph: for each message-publishing origin (Wolverine handler, HTTP endpoint, scheduled job, …) it discovers which messages that origin publishes and renders a chain detail page. The JasperFx.Events
PublisherKindenum already reservesGrpcEndpoint, but nothing populates it — there is no first-class way to discover a gRPC service method as a Wolverine message-publishing origin.For HTTP this works because
WolverineFx.Httpchains expose endpoints as discoverable origins that the JasperFx.Events source generator can analyze forIMessageBus/InvokeAsync/PublishAsynccalls and emit publisher origin (route + method). gRPC has no equivalent surface: aGrpc.AspNetCoreservice method that calls into Wolverine to publish a message is invisible to the generator, soPublisherKind.GrpcEndpointstays unpopulated and a gRPC chain detail page has no data.The ask
A first-class gRPC endpoint discovery surface — a convention/attribute (and the generator support to read it) that lets a gRPC service method be recognized as a Wolverine message-publishing origin, emitting
PublisherKind.GrpcEndpointwith route/method origin (service + method, proto-derived metadata where reachable) — analogous to how HTTP endpoints are discovered today.Open design question (why this is filed as discussion)
It is genuinely unclear whether this belongs in Wolverine at all. gRPC services are ASP.NET-owned; Wolverine has no gRPC integration package today, and the CritterWatch lifecycle-assembler work (#396 Phase 2, "B3") already flagged gRPC as "likely N/A, deferring unless a convention emerges." Two plausible shapes:
WolverineFx.Http). Heavyweight; only worth it if gRPC-as-message-entrypoint is a pattern Wolverine wants to bless.GrpcMethodMetadata), without aPublisherKind.GrpcEndpointevent-model origin.This issue exists to make that decision explicitly rather than leaving
PublisherKind.GrpcEndpointreserved-but-dead.Downstream (CritterWatch)
post-1.0on the CritterWatch side.