[Bug]: `validateFn` does not propagage errors upwards

[gabyx]

What happened?

when using

package main

import (
	"errors"
	"fmt"

	val "github.com/go-playground/validator/v10"
)

type S struct {
	A string `validate:"validateFn"`
}

func (s *S) Validate() error {
	return errors.New("huha")
}

func main() {
	var s S
	e := val.New().Struct(&s)

	fmt.Printf("%v", e)
}

on a struct field A, the Validate() error function is called but the error returned from that function is never accesible in the result e.

Only an error:

Key: 'A' Error:Field validation for 'A' failed on the 'validateFn' tag"

is printed.

Also casting to validation.ValidationError does not help.

Version

10.30

Example Code

see above.

[peczenyj]

Hey, the root cause of this issue is the inner validate interfaces that must return a boolean. there are no inner errors, or causes. To be possible change (and expose the root cause) this I think it is a big change in the internals of this validator. What I can suggest is:

• we could inject a logger (*slog.Logger or just a printf) that we can specify globally (like by default it just discard but we can use a Verbose logger, etc) or per validator struct (but each validator must decide what to log, what level, if needed)
• we could specify callbacks to be executed in case of a deep error. this can be interesting to do more things that just log
• we could effectivelly change the internal interfaces to return an error (and it can be useful, to know why something fail with more detail)

some suggestions may be already proposed (and even rejected), we must check the previous discussions. I could prepare some pull requests in the next days but only if the maintainers of this project give me green light, I cant put energy in something that will be rejected anyway

[zemzale]

The root cause is exactly what @peczenyj says. The issue with trying to rework this and allow for gathering extra info is very simple: translations.

Translations work by finding the tag and based on that translate the error. Even changing the internals to take an error would still not fully work with the current translations pipeline.

I know that they are not really supported with the current implementation (outside of the generic message), so maybe we can figure something out?