Surface the gRPC manifest via a ServiceCapabilities descriptor source (GH-3267)#3268
Merged
jeremydmiller merged 1 commit intoJun 27, 2026
Merged
Conversation
…iptor source (GH-3267) The gRPC endpoint manifest (GH-3266) lived only inside Wolverine.Grpc and never reached the ServiceCapabilities capability path, so a monitoring console (CritterWatch) had no way to discover the gRPC services a Wolverine app exposes the way it discovers HTTP chains (IHttpGraphUsageSource) and ASP.NET endpoints (IAspNetEndpointDescriptorSource). This adds the parallel descriptor/source plumbing for gRPC: - GrpcRpcDescriptor : OptionsDescription (Wolverine core, next to ServiceCapabilities) carrying per-RPC service name, method, RPC kind, the published/request message type, response type, and the forwarding origin (all types as serializable TypeDescriptors). - IGrpcEndpointDescriptorSource — discovery source mirroring IAspNetEndpointDescriptorSource; registered in DI by Wolverine.Grpc, projecting the runtime IGrpcEndpointManifest into descriptors. - ServiceCapabilities.GrpcEndpoints + readGrpcEndpoints, folding every registered source into the snapshot ordered by service::method (mirrors AspNetEndpoints). The descriptor lives in Wolverine core rather than JasperFx.Descriptors: ServiceCapabilities is itself a Wolverine-core type and CritterWatch already references WolverineFx, so a core-resident descriptor is equally consumable without a coordinated JasperFx release. Hand-written and direct-mapped services stay excluded (inherited from the manifest) — they delegate to user code and have no message-publishing origin. Adds coverage across every supported configuration: proto-first unary/server-streaming/bidirectional and code-first unary/server-streaming through both the raw source and the end-to-end ServiceCapabilities.ReadFrom path, plus the no-gRPC (empty, no source registered) case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 29, 2026
Open
Merged
This was referenced Jul 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3267. Builds on #3266.
Summary
The gRPC endpoint manifest (
IGrpcEndpointManifest, #3266) lived only insideWolverine.Grpcand never reached theServiceCapabilitiescapability path. A monitoring console (CritterWatch) therefore had no way to discover the gRPC services a Wolverine app exposes — the way it already discovers HTTP chains (IHttpGraphUsageSource) and ASP.NET endpoints (IAspNetEndpointDescriptorSource) viaServiceCapabilities.ReadFrom.This PR adds the parallel descriptor/source plumbing for gRPC:
GrpcRpcDescriptor : OptionsDescription(Wolverine core, besideServiceCapabilities) — one per RPC, carrying service name, method, RPC kind (GrpcRpcStreamKind), discovery mode, the published/request message type, response type, and the forwarding origin. Types are serializableTypeDescriptors;SubjectisGrpcEndpoint[Service/Method]and each is taggedgrpc.IGrpcEndpointDescriptorSource— discovery source mirroringIAspNetEndpointDescriptorSource; registered in DI byWolverine.Grpc, projecting the runtimeIGrpcEndpointManifestinto descriptors (lazy + cached).ServiceCapabilities.GrpcEndpoints+readGrpcEndpoints— folds every registered source into the snapshot, ordered byservice::method(mirrorsAspNetEndpoints).Design note — why Wolverine core, not JasperFx.Descriptors
The issue suggested putting the descriptor in
JasperFx.Descriptors(mirroringAspNetEndpointDescriptor). ButServiceCapabilitiesis itself a Wolverine-core type and CritterWatch already referencesWolverineFx, so a core-resident descriptor is equally consumable — without a coordinated JasperFx release and a 2.16→2.18 pin bump. This keeps #3267 a single self-contained PR. Hand-written and direct-mapped services stay excluded (inherited from the manifest): they delegate to user code and have no message-publishing origin.Test coverage
grpc_capabilities_descriptor_source_3267.cs— across every supported gRPC configuration, through both the rawIGrpcEndpointDescriptorSourceand the end-to-endServiceCapabilities.ReadFrompath:SayHello)grpctagStreamGreetings)Echo, viaBidiStreamingFixture)Greet)StreamGreetings)IAsyncEnumerable<T>element responsegrpctag; capabilities ordered by service::method; only bus-forwarding modes surfaceGrpcEndpointsempty and no source registeredLocal:
Wolverine.Grpc.Tests247/247 + the CoreTests capability/ReadFromacceptance suite 24/24 (net9.0).🤖 Generated with Claude Code