Skip to content

[Feature Request] Allow specifying human-readable error message next to the validation definition #423

@PierekEast

Description

@PierekEast

Feature description:
The ability to define human-readable error messages that are returned when a validation rule fails. This would allow developers to specify custom, user-friendly strings instead of the default, technical validation errors.

Problem it solves or use case:
Currently, protovalidate returns a technical error message based on the specific validation rule that failed (e.g., validation error:\n - requests[0].technical_contact.email: value is empty, which is not a valid email address [string.email_empty] While this is useful for debugging, it's often not suitable for direct use in an application's user interface or API responses. This feature would solve this by allowing developers to provide clear, business-logic-related error messages to the end-user, such as "Please enter a valid email address." or "The password must be at least 8 characters long." This hides the internal validation logic from the caller and provides a better user experience.

Proposed implementation or solution:
A new Protobuf option could be added to the field-level validation rules to specify a custom error message. The validator would then return this custom message if the corresponding rule fails.

Here is a simplified example of how this could be implemented within a .proto file:

(validate.rules).string = {min_len: 1, pattern: "^environments/[a-zA-Z0-9_-]+/contact$"},
(custom_options.v1alpha1.customer_facing_error) = "full contact path must be provided in the 'environments/{environment}/contact' format"

Examples or references:
I know that there is a little bit of this in CEL validations:

// `Violation` represents a single instance where a validation rule, expressed

But I do not think that all validations should be defined using CEL and it is much clearer to specify simple field validation with a human-readable error message

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions