[#55382] add connection validation section

[Kharonus]

#55382

WAT?

• added connection validation section to sidebar
  • allows manual request of a health check for this storage
  • checks for tenant id, drive id, oauth credentials, AMPF content
• added new controller for connection validation
• show connection validation only for one drive storages

[akabiru]

Nice one @Kharonus 🏆 I have a couple of 🟢 & 🟠 but nothing blocking. Shout if easier to chat/pair 🙂

[akabiru]

🟢 The monads are a really nice touch, but I wonder if we can follow a positive naming scheme- the negation based naming can sometimes be confusing (at least to me)

Suggested change

	maybe_is_not_configured
	.or { tenant_id_wrong }
	.or { client_id_wrong }
	.or { client_secret_wrong }
	.or { drive_id_wrong }
	.or { request_failed_with_unknown_error }
	.or { drive_with_unexpected_content }
	.value_or(ConnectionValidation.new(type: :healthy, timestamp: Time.current, description: nil))
	maybe_storage_configured
	.or { validate_tenant_id }
	.or { validate_client_id }
	.or { validate_client_secret }
	.or { validate_drive_id }
	.or { request_failed_with_unknown_error }
	.or { drive_with_unexpected_content }
	.value_or(ConnectionValidation.new(type: :healthy, timestamp: Time.current, description: nil))

[Kharonus]

Ah, well, that is interesting. Especially due to the or concatenation I naturally read negative namings. It seems more natural then the positive way.

See this imaginary monologue.

"So, I have this storage.... I suspect it to be invalid."
"Maybe the storage is not fully configured?"
"Well, apparently it is... so, is then tenant id wrong?"
"Hmm, not... what about the client id?"
"Or the client secret?"
"Anything of that? No? Then apparently you are valid."

Get what I am pointing at? :D validations are "positive" when they are "negative", hence finding a problem means, your validation was justified.

[akabiru]

Get what I am pointing at? :D validations are "positive" when they are "negative", hence finding a problem means, your validation was justified.

I see wym for sure, and perhaps ActiveModel::Validations are a great conventional example; they only push to errors in the even "negative" event that there's a validation failure, otherwise they just return ?true.

Hence in your imaginany monologue 😄 mine would read like so:

"So I have this storage... I need to validate that everything is configured properly"
"Firstly, validated it is fully configured"
"Then, validate the tenant id is correct"
"Then, validate the client id is correct"
"Then, validate the client secret is correct"
"When there are invalid cases, collect them and display a unified response (similar to active_model_errors) to the user"
"When there are no errors, return- mark the storage connection as valid"

---

I reckon what's different with my monologue is that I presume we're collecting all errors- and displaying them once to the user, but AFAICT- we fail fast on the first error result? In which case that might be inconvenient if the user has to click the button multiple times because they are served one error at a time.

In which case, I wonder if just mixin in ActiveModel::Validations and writing these as validate statements would be more fitting albeit less "Monad-ish" 😄

[mereghost]

but AFAICT- we fail fast on the first error result?

Here's the trick, except for the missing/empty values, it is impossible to validate if the previous validation has failed. If the tenant id is wrong, we can't validate the Client ID/Secret, if the Client ID/Secret is wrong we can't validate the Drive ID.

In which case, I wonder if just mixin in ActiveModel::Validations and writing these as validate statements would be more fitting albeit less "Monad-ish" 😄

There are always more than one way to do things. A dry/validation contract, ActiveModel::Validations or a chain of assertions all could do the same thing.

1. ActiveModel would be tied directly to an object (with certain assumptions).
2. Dry::Validation::Contract would create an object just for validation of a hash/json that could be passed down after validation.
3. A chain of assertions (in this case using the Maybe/Option monad) makes explicit the validation process.

[Kharonus]

Here's the trick, except for the missing/empty values, it is impossible to validate if the previous validation has failed. If the tenant id is wrong, we can't validate the Client ID/Secret, if the Client ID/Secret is wrong we can't validate the Drive ID.

Yes, and here we should design it, as the domain user story is telling us. And here, it was set, we do not show all errors. We do show the first error, that can happen. Hence, the implementation follows that story, and fails with the first error, not checking for the other validation rules.

[akabiru]

Cheers Eric!