Different error message for dev and prod environments

[ilzrv]

Is there a way for different environments (development, production) to use different error descriptions?

For example, in a dev environment, errors can be displayed completely:

{
    "code": "internal",
    "msg": "internal error",
    "meta": {
        "cause": "Secret Exception Message"
    }
}

But in the prod environment the original error message should be hidden:

{
    "code": "internal",
    "msg": "internal error",
    "meta": {
        "cause": "Internal Server Error"
    }
}

Is there any possibility to implement this?

[sagikazarmark]

I don't think that's possible with the library at the moment. However, I don't think that's a good practice either.

For one, it would be the source of all kinds of confusion why the app behaves differently in dev.
Secondly, having different habits for debugging service-to-service communication in dev and prod can also easily lead to problems when the house is on fire.

[ilzrv]

If this is used on the site frontend, it's not safe to show real error messages. Don't you think so?

[sagikazarmark]

It depends on the errors. Secret Exception Message suggests it's an internal error. No, I don't think that should ever be shown on a frontend.

If it's a business error though (eg. some resource cannot be found), you can convert the error to a Twirp error, specifying a message and an error code. But I assume this is not the case here.

[ilzrv]

If it's a business error though (eg. some resource cannot be found), you can convert the error to a Twirp error, specifying a message and an error code. But I assume this is not the case here.

Are you talking about errors that I throw myself(TwirpError)?

[the-toster]

I think it's possible by passing custom response factory to the generated server constructor.

[sagikazarmark]

Are you talking about errors that I throw myself(TwirpError)?

Yes, you should convert business errors to twirp errors manually.

I think it's possible by passing custom response factory to the generated server constructor.

Yep, that's one way to do it. Implementing interceptors might also be a good way.

I'm closing this issue for now. If you want to continue the discussion, please start a new one under Discussions. Thanks!