Type safety with "int", improved err handling and toolset addition nit

[shivavishaal66215]

Type Safety

int usage

• int as a type has been used in quite a few places in code (including amount handling).
• Given that int is platform dependent, this usage could lead to inconsistent behaviour or unexpected truncations .
• int32 or int64 will offer consistent behaviour.

float64 to int conversions

• There are quite a few unsafe conversions from float64 to int - these have to be updated for safety since there's an overflow risk
• Example:

// If it's certain that `value` will always be in bounds of `int`, then `float64` isn't required at all.
func Min(value float64) PropertyOption {
	return func(schema map[string]interface{}) {
		propType, ok := schema["type"].(string)
		if !ok {
			return
		}

		switch propType {
		case "number", "integer":
			schema["minimum"] = value
		case "string":
			schema["minLength"] = int(value)
		case "array":
			schema["minItems"] = int(value)
		}
	}
}

Error handling improvements

Current structure

amount, err := RequiredInt(r, "amount")
if result, err := HandleValidationError(err); result != nil {
	return result, err
}

// Get and validate currency
currency, err := RequiredParam[string](r, "currency")
if result, err := HandleValidationError(err); result != nil {
	return result, err
}

// Get and validate receipt (optional)
receipt, err := OptionalParam[string](r, "receipt")
if result, err := HandleValidationError(err); result != nil {
	return result, err
}

// Get and validate notes (optional)
notes, err := OptionalParam[map[string]interface{}](r, "notes")
if result, err := HandleValidationError(err); result != nil {
	return result, err
}

Slightly better error handling

• Fail-fast error handling in places like above would require user to fix each input error 1 by 1
• Providing the list of errors as 1 single output would be better IMO

Example

• Say the input does not contain both amount & currency.
• In the current implementation, I don't get to know about currency problem until I fix amount problem.
• In the suggested implementation, I get to know about both missing fields at once.

Toolset Addition

Current:

toolsetGroup.AddToolset(payments)
toolsetGroup.AddToolset(paymentLinks)
toolsetGroup.AddToolset(orders)

Slightly better (D.R.Y.)

toolsetGroup.AddToolsets(payments, paymentLinks, orders)

And, looks like all toolsets are enabled by default if none are explicitly enabled. Although there's nothing particularly wrong with this, it's human nature to assume nothing will be enabled if I'm not enabling anything. 🤔

[alok87]

ack we will get back // @KarthikBoddeda @ChiragChiranjib