It was an intentional behavior change. Users with non-existing plugins are skipped during the load (just as users with host names if skip-name-resolve is used), so, practically, they don't exist.

The warning from FLUSH PRIVILEGES could've been better, though. Currently it does not say "user was skipped"

It seems to be a pretty bad behavior change, why would we do that, what are we trying to achieve?

Instead of a rather clear message "plugin not loaded" the user will start getting obscure "Access denied", which can be caused by a number of reasons. It makes things more difficult for an account admin and more obscure for a user who can't login. What's the gain?

Even worse if you have a "stronger" and a "weaker" account for the same username, e.g. `foo@localhost` and `foo@'%'` (not mentioning anonymous account, which can be declared bad practice). Then, skipping the first one will cause the next one be picked up silently, which can be both unexpected and unwanted.

Making it as bad as skip-name-resolve doesn't seem to be a valid reason. Besides, skip-name-resolve is an active configuration, an admin at least makes it so intentionally (although I wouldn't blame them for not expecting such obscure side-effects). Non-existing plugin is a passive configuration, it's something somebody hasn't done, or even worse, something went wrong on a server/plugin side upon loading the plugin.

A better warning on FLUSH PRIVILEGES won't solve anything, it was just there for simpler reproducing. In reality most problems will happen upon server restart.

On a separate yet related note, how is it going to play along with the planned multiple authentication methods? If you are going to ignore the account completely because the plugin is not loaded, how can other methods be used?

Why: because before MDEV-12321 the server could load a user without a plugin and later, during an authentication attempt, to find out that a plugin wasn't available. After MDEV-12321, the server needs a plugin to load the user, without a plugin it doesn't know how to interpret the authentication string and whether it needs to be pre-processed on load. The easy solution was to skip users with an unknown plugin — installing a new plugin is a rare operation, uninstalling a plugin that has existing accounts using it is ever rarer.

Another solution would be to implement "lazy initialization" — mark an account as incomplete and finish the pre-processing on the first authentication attempt. I don't know if it's an important use case to cover, though.

It does seem strange that we forsake usability in an unfortunately rather common scenario as a result of internal implementation of some rather obscure feature which we don't even know whether anybody needs or going to use.

And yes, the scenario with a missing plugin appears to be fairly common – a big part of my stackoverlow activity was devoted to explaining why users can't login when unix_socket is not loaded.

Please at least have the change documented explicitly somewhere. It won't help users, but it will give us a permanent link to refer to, instead of explaining every time again that it was done intentionally and why.

If it's a fairly common scenario, it needs to be covered. I'll reopen the issue.

I didn't mention another fancy side-effect of the same change:

...

MariaDB [test]> SHOW CREATE USER foo;

ERROR 1133 (28000): Can't find any matching row in the user table

MariaDB [test]> CREATE USER foo;

ERROR 1133 (28000): Can't find any matching row in the user table