The cached user list is refreshed (within users_reload_time / users_refresh_interval) limits if a client tries to connect using a user/host/password combination not known to the local cached user list.

A user list refresh is not triggered though if the auth information provided matches what the maxscale user list cache has, but then backend authentication fails as the cached information is no longer valid. E.g. due to a DROP USER.

At this point it is probably too late to report the auth failure back to the client as Maxscale already sent an OK to the client, so it can only react by terminating the client connection instead.

But Maxscale should still take this as a trigger event to update the cached user data, as right now this can lead to the client trying to connect again and again, each time receiving a "authentification OK" followed by "server has gone away"/"connection terminated", without knowing what the actual problem is.

The client should instead just get "connection terminated" just one, after that the user list cache should be reloaded, or at least the failed entry being invalidated so that a proper error can be returned to the client on the next connection attempt.

• a user data fresh is triggered – within users_reload_time limits – if a client provides a user/host/password combination not known to maxscale
• it is not triggered though if the supplied information matches the cached information, and only fails later when doing actual backend authentication

1) maxscale should reload its cached userlist better. It only handles half of the job ("new user" part is ok, but "drop/alter user" part is not ok)
2) maxscale should not try to connect indefinitely because the credentials are ok according to its cache, it should stop after X tries and return the error message received from the backend to the client if none of those X tries were successful