Is the NOT_FOUND response codes in gRPC an actual error, or could one use it to indicate a resource doesn’t exist — and it doesn’t matter if it doesn’t — on the happy path?

There seems to be a bit of disagreement to what degree non-200 OK error codes should be used to signal non-error conditions. I’m generally of the opinion that all the 4xx HTTP response codes are not actually errors, and should be available to the developer to indicate that, while the method execution was not quite as expected, it wasn’t adverse in a way that warrants error logs or PagerDuty alerts. That’s what the 5xx response codes are for.

When I discussed this with someone at work, they came up with a decent enough counter-point. Suppose you’ve accidentally missed-configured a URL of a micro-service, and when you hit that URL you get 404s. Arguably that does warrant error logs and PagerDuty alerts, especially if the quality of service is degraded and you want to get it fixed as soon as you can.

So I can see how the HTTP response codes for a REST-API can be ambiguous here. But is it the same for a gRPC API? Since gRPC has UNIMPLEMENTED to indicate a miss-configured service, can a developer use NOT_FOUND for out-of-band non-error signalling? Should error codes be used at all, and the response code be OK with the response body itself having in-band signalling to indicate that a resource isn’t found but that’s OK?

Don’t know the answer to this.