Validation error when trying to map attributes

This is a self review of code I (re)wrote last december, which hasn't received much feedback yet.

The above message is logged if the following method returns FALSE:

https://git.drupalcode.org/project/samlauth/-/blob/8.x-3.x/modules/samla...

So my first guess / question is: does field_first_name actually exist as a field on the user? Was it maybe deleted after the mapping was set?

If so, I should add an error log message saying that. (And I think we should still fail - because this would be a "I don't know what is happening here but the site administrator can fix it, and therefore should fix it before we are willing to go on" kind of error.)

That will require some debugging then. Because the inside of

$field_definition = $account->getFieldDefinition($account_field_name);

are unknown territory to me, and I don't know when/why they would return an empty value

That... or overriding the samlauth_user_fields.event_subscriber.user_sync service with a custom child class

class MySubscriber extends UserFieldsEventSubscriber {
  
  protected function validateAccountFieldValue($input_value, UserInterface $account, $account_field_name) {
    // User field validation fails for some reason and we don't want to find
    // out why, right now. We'll trust our setup / attribute values implicitly.
    return TRUE;
  }
}

...and leaving this issue open until that time when you want to debug and/or someone else comes along.

Argh - thank you!

Strange I didn't spot this myself while testing.
Edit: I figured you could just cast a Countable to a boolean, and that would always evaluate to FALSE if its count value is 0. Hence the!(bool) $violations; rather than just !$violations;. So I don't get that part... yet.

I'll kick it around some more.

This will go in before the 3.0 release.

Actually you're right, and there's no need for me to 'act smart'.

$data->validate() returns a ConstraintViolationListInterface. There's no need for me to second guess the interface specs and assume it might e.g. return NULL. So I can just call count().

Thanks again.

LOL. I should never quickly commit a fix in between other things, that always goes wrong.

Which I'm now, of course, saying while quickly committing a fix in between other fixes, because stubborn :p

(So now that we always have a countable, let's do a little more reorganisation.)