graphql: validate block params

[s1na]

Block takes a number and a hash. The spec is unclear on this. My interpretation is either of these should be provided and we should error in case both are passed in.

Fixes #25899

[wsb1994]

Hi, I personally disagree with the direction this goes -> Not because this is a bad idea, but because there is a language centric method of validation for things like this already in go-validator, here is an example of how that might look, although I'll allow you and the reviewer to decide on what that means for this PR and allow you to retain the edit :)!

func (r *Resolver) Block(ctx context.Context, args struct {
	Number *Long
	Hash   *common
}) (*Block, error) {
	// Validate input arguments
	err := validateBlockArgs(args)
	if err != nil {
		return nil, err
	}

above is the validation function, using go-validate, which would then run the validation and return an error inline.

This is a much more go-thonic and sustainable way to do validation throughout etherium. This could compromise a substantial value add for other areas of the etherium project as well, providing more sustainable and expandable validation in many areas of the codebase.

[karalabe]

@wsb1994 I don't think we want to go down the route of annotating validation rules in struct tags. We use a handful of consensus structures which have wildly different validation criteria based on which entrypoint they appear in our codebase. Whether network propagation, RPC APIs, sync vs. block processing, etc.

All in all I am not a fan of declarative rules, they almost always lack some flexibility that results in the same old custom code needing to be written anyway.

[holiman]

LGTM