[stable19] makes LDAP's group updater dispatch type events

[blizzz]

essentially #22771 for stable19

[MorrisJobke]

Code looks good 👍

[faily-bot]

🤖 beep boop beep 🤖

Here are the logs for the failed build:

Status of 32964: failure

acceptance-app-files

• tests/acceptance/features/app-files.feature:108

Show full log

  Scenario: show shares                                               # /drone/src/tests/acceptance/features/app-files.feature:108
    Given I am logged in                                              # LoginPageContext::iAmLoggedIn()
    And I share the link for "welcome.txt"                            # FilesAppSharingContext::iShareTheLinkFor()
    When I open the "Shares" section                                  # AppNavigationContext::iOpenTheSection()
    Then I see that the current section is "Shares"                   # AppNavigationContext::iSeeThatTheCurrentSectionIs()
    Then I see that the file list contains a file named "welcome.txt" # FileListContext::iSeeThatTheFileListContainsAFileNamed()
      Row for file welcome.txt in file list could not be found after 100 seconds (NoSuchElementException)

[rullzer]

🐘

[steffen-moser]

Oddly, we do see the broken behavior which is initially described in #22771 since 19.0.4. We do it still see in 19.0.5. We have not seen it in previous versions (18.x).

It only happens with a combination of a group and a user and we just do not know what makes them special. We recognized it because we began to see the following error in the log (when the UpdateGroups.php runs) after we put a new user into a long-existing LDAP group where a share has been connected to for months...

{"reqId":"eeN9hTtXVkGWW0gdLU21","level":1,"time":"2020-11-21T08:47:07+00:00","remoteAddr":"","user":"--","app":"user_ldap","method":"","url":"--","message":"bgJ \"updateGroups\" \u2013 Dealing with known Groups.","userAgent":"--","version":"19.0.5.2"}
So we see that NC's background job wants to check whether users have to be added or removed to or from existing groups (I changed the log level of this message to avoid the log being flooded with DEBUG messages at this time).

{"reqId":"eeN9hTtXVkGWW0gdLU21","level":1,"time":"2020-11-21T08:47:47+00:00","remoteAddr":"","user":"--","app":"user_ldap","method":"","url":"--","message":"bgJ \"updateGroups\" \u2013 \"cb79192e-b1eb-103a-90f5-xxxxxxxxxxxx\" will be added to \"bmwiss-azr-teachers-wise2021\".","userAgent":"--","version":"19.0.5.2"}
This is a debug output I added to lines 129 - 131 to see where the problem occurs. So, NC's GroupUpdate has found a user that should be (according to LDAP) added to the group record in "oc_ldap_group_member". But we never see a successful adding...

...Instead, we get:
{"reqId":"eeN9hTtXVkGWW0gdLU21","level":3,"time":"2020-11-21T08:47:47+00:00","remoteAddr":"","user":"--","app":"core","method":"","url":"--","message":{"Exception":"OC\\Share20\\Exception\\ProviderException","Message":"Recipient not in receiving group","Code":0,"Trace":[{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/lib/private/Share20/Manager.php","line":1081,"function":"acceptShare","class":"OC\\Share20\\DefaultShareProvider","type":"->","args":[{"__class__":"OC\\Share20\\Share"},"cb79192e-b1eb-103a-90f5-xxxxxxxxxxxx"]},{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/apps/files_sharing/lib/Listener/UserAddedToGroupListener.php","line":73,"function":"acceptShare","class":"OC\\Share20\\Manager","type":"->","args":[{"__class__":"OC\\Share20\\Share"},"cb79192e-b1eb-103a-90f5-xxxxxxxxxxxx"]},{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/lib/private/EventDispatcher/ServiceEventListener.php","line":76,"function":"handle","class":"OCA\\Files_Sharing\\Listener\\UserAddedToGroupListener","type":"->","args":[{"__class__":"OCP\\Group\\Events\\UserAddedEvent"}]},{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php","line":251,"function":"__invoke","class":"OC\\EventDispatcher\\ServiceEventListener","type":"->","args":[{"__class__":"OCP\\Group\\Events\\UserAddedEvent"},"OCP\\Group\\Events\\UserAddedEvent",{"__class__":"Symfony\\Component\\EventDispatcher\\EventDispatcher"}]},{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/3rdparty/symfony/event-dispatcher/EventDispatcher.php","line":73,"function":"callListeners","class":"Symfony\\Component\\EventDispatcher\\EventDispatcher","type":"->","args":[[{"__class__":"Closure"}],"OCP\\Group\\Events\\UserAddedEvent",{"__class__":"OCP\\Group\\Events\\UserAddedEvent"}]},{"file":"/srv/www/vhosts/polaris/htdocs_ssl/owncloud/lib/private/EventDispatcher/EventDispatch

We just do not know what makes this user and group special. Both, the (Open)LDAP records of user and group and the LDAP-related MySQL tables for LDAP users and groups look normal. The user will never make it to this group's record in "oc_ldap_group_member", but he interestingly can see the group share when he logs in. We get this error whenever the UpdateGroups runs. We suppose that somewhere in

$dispatcher->dispatchTyped(new UserAddedEvent($groupObject, $userObject));

the problem happens, but why?

Version 19.0.5, which has #23895 (the backport of #23799) integrated, does not seem to fix it. The same problem goes on. Does anybody observe a similar problem since upgrading to 19.0.4?