Small correction: As per my manual test, looks like the client call actually hangs forever: I don't see the request completed even after several minutes.

This seems to be the case becuase grpc's RegisterService which we call (
https://grpc.io/grpc/cpp/classgrpc_1_1_server_builder.html#a0b06b5828b892feeb6541c8eeae2d542 ) actually iterates all methods in the service and already registers them.

There doesn't seem to be a good way to avoid this behavior without a lot of complexity.

If the service definition at compile time didn't have a method, it _will_ answer a grpc error with the value UNIMPLEMENTED. I'll confirm this with a test case.

Assuming this is the case, is it OK to rely on the server calling RegisterHandler for all functions that are in the service definition at compile time?
I guess we would do this inside DPSL for all defined methods anyway, so it is not forgotten in diagnostics_processor.

Or do you think there's enough value to investigate additional safeguards (such as attempting to find out if there are methods that were not registered somehow and CHECK-failing then)?

Thanks for investigating.

So does the case "client is run against an older version of server which didn't have the new method" work differently, without hanging?
If so, it should be OK to leave it as is.

I wanted to write a test case for this, but it's hard to reproduce this case exactly (of the same service having one method less) because grpc uses the names from the proto descriptor (and I can't customize these).

However, at grpc level, it seems that a "service name" doesn't exist as a concept, resolution happens on method names instead.

For example, in the tests, the following is generated:
static const char* ExampleService_method_names[] = {
  "/diagnostics.test_rpcs.ExampleService/EmptyRpc",
  "/diagnostics.test_rpcs.ExampleService/EchoIntRpc",
  "/diagnostics.test_rpcs.ExampleService/AnotherEchoIntRpc",
};

when a call arrives, the matching is performed by comparing the call's "path" against the registered method (rm)'s method name - see https://github.com/grpc/grpc/blob/04c34590c6cdda071533b07dee987625f9f7aca7/src/core/lib/surface/server.cc#L621 .

This means that the situations
- Server exposes Service S without method M, Client tries to call method M of Service S
- Server does not expose Service S at all, Client triest to call method M of Service S
should be equivalent.

For the latter situation, there's https://github.com/grpc/grpc/blob/618a3f561d4a93f263cca23abad086ed8f4d5e86/test/cpp/end2end/end2end_test.cc#L1165

So we should be fine here.