ExperimentalError thrown by a networkService request
OptionalrequestType: stringIf provided, additionally require the error to name this request type, so a method-not-found response for some other request cannot be mistaken for this one's. Both producers embed the raw request type in their message.
Whether error is a method-not-found response (for requestType, when given)
Whether
erroris whatnetworkService's request plumbing (doRequestinnetwork.service.ts) throws for a JSON-RPC "method not found" response — i.e. no handler for the requested method has registered anywhere on the network.Callers that want to treat "nobody is listening" as a benign outcome must key off the JSON-RPC error code, never off the human-readable text that follows it. The two producers of a method-not-found response word that text differently (
'<method>' not foundinrpc-server.ts,No handler found for <method>inrpc-websocket-listener.ts), and matching the text alone also matches an unrelated failure from a handler that did run and threw a message with the same words in it — turning "no validator, allow it" into "the validator rejected this, allow it anyway". The code is the only part that distinguishes the two.The code has to be read back out of the message because
doRequestflattens every RPC-level error — method-not-found and a handler throwing alike — into a thrown value whosemessageisJSON-RPC Request error (${code}): ${message}, with no other machine-readable marker (the richerplatformErrorCodefield is populated only for C#PlatformErrorCodes.WithCodethrows, which a "no handler yet" response never carries — it has noerror.dataat all). Deriving the format from getJsonRpcRequestErrorMessagePrefix, the same producerdoRequestbuilds the message with, keeps this matcher in lockstep with any reformat there.