What concerns are there for deleting an RPC from a service?

We have inherited a GRPC service which has a service definition like:

service MyService
{
    rpc RPC1() returns (something)
    rpc RPC2() returns (something)
    rpc RPC3() returns (something)
    ...
    rpc RPC10() returns (something)
}

In reality we only use RPC1 to RPC3 but none of the other RPC's and end clients only use RPC1 through RPC3.

To clean up our code - I'd like to delete the other RPC's (4 through 10). I've seen that you can mark them as deprecated but to make things cleaner I'd really prefer to delete them instead.

I've seen posts mentioning that you shouldn't delete fields because we could run into issues with the field number if a future field uses that field number again. So for fields you can do something like - reserved 5 to 10; to prevent these field numbers from being used. But I'm not sure if there's similar things to watch out for when it comes to RPC's.

I was wondering in the case of deleting RPC's from services what concerns there were - provided the context I highlighted above about how we have confidence RPC's 4 through 10 are not used.

gRPC uses the "protobuf package + service name + method name" as the RPC method identifier, so managing them should be pretty predictable. Services don't really exist on the wire protocol, other than to provide a namespace, so deleting methods and deleting a service behave similarly.

If you delete a method (or service) and a client is actually using it, the client will receive UNIMPLEMENTED. If you create a new method with the same name and an old client is actually using it, it would send the wrong message type and you'd get pretty confusing results.

For a service without control over its clients, you should leave the methods in place and potentially have them return clear errors. If you have a good understanding of your clients or have confirmed that the methods aren't used via monitoring, you can simply delete them. It is very similar to deleting an unused service.