This relates to CONTROLLER-2065.

The process of modeling, implementing and using routed RPCs is documented here.
From that, it is clear that there needs to be context reference in the input of a routed RPC. The context reference is an instance identifier referencing context instance in which the RPC should be executed.

The buy-car RPC declaration declares that its context-reference is person-context from module people@2014-08-18:

rpc buy-car {
    description
      "buy a new car";
    input {
      leaf person {
        ext:context-reference "person:person-context";
        type person:person-ref;
        description "A reference to a particular person.";
      }

      leaf car-id {
        type car:car-id;
        description "identifier of car.";
      }
      leaf person-id {
        type person:person-id;
        description "identifier of person.";
      }
    }
  }

So, when calling this RPC the body of the request could look like this

{
    "input": {
        "person": "/people:people/people:person[id=\"0\"]",
        "car-id": "0",
        "person-id": "0"
    }
}

This is executed successfully with return status 204 No Content.

As stated in the previously mentioned documentation on routed RPCs, there should be an implementation of an RPC for a particular context instance. It also states, that "If user invokes RPC with a context instance that has no registered implementation, the RPC invocation will fail with the exception DOMRpcImplementationNotAvailableException."
That would mean, that if an implementation of a buy-car RPC for the given context (in this case for an instance of a person with id 0) was not registered, the RPC should fail. The truth is, that it was NOT registered (implementation of buy-car RPC for a particular context is registered when new person instance is added via add-person RPC
[Note: add-person RPC is not registered, the registration needs to be added in the code (probably in the PersonProvider.java)]), but it doesn't fail.

This is rooted in the processing of a*routed RPC*, thus lets see how it works.
This is no longer in controller, it is taken care of by mdsal's DOMRpcRouter.

• If a routed RPC is being invoked, the DOMRpcRouter checks if the body contains an instance identifier of the context reference declared in the yang model
• if it DOES NOT, it checks whether there are any mapping of null identifier to any implementation and if not, the RPC fails (if yes, the found implementation is executed)
• if it DOES, it looks for a specific implementation of the RPC (specific == implementation of the RPC for the given context)
  • the specific implementation is executed, if it exists
  • if it does not exist, it checks if there is any implementation for a "wild card" (as described in the comment "Find a DOMRpcImplementation for a wild card. Usually remote-rpc-connector would register an implementation this way") ...

    final List<DOMRpcImplementation> mayBeRemoteImpls = entry.getImplementations(YangInstanceIdentifier.empty());

    ... which in case of buy-car gives us something that looks like a global implementation of the buy-car RPC (this "global" implementation is registered, when PeopleProvider service is activated)

Summary of peculiarities:

1. The buy-car RPC does not fail, when the implementation for the given context is missing.
2. The buy-car RPC does fail, when no context reference is given in the input example in the related issue
3. The input of the buy-car contains
   • reference to a particular person by specifying their id
   • car-id
   • person-id
     but the person-id and the id (extracted from the given person reference) are not connected in any way
4. The error message, received when the input is missing the context reference is vague (example in related issue). Sure, the implementation for the not given context is missing, but the error message makes it seem, like there is no implementation of the buy-car RPC whatsoever. Wouldn't it be better to inform the user about the missing context reference? (mdsal)