After Update to 23.1, eGroupware floods MySQL with queries.

Client running Windows + Thunderbird 102.9.0 starts to sync eGroupware Calendar + eGroupware Infolog via GroupDAV. Calendar sync is successful (once), Infolog sync will start an endless loop in eGroupware. The MySQL backend reports queries:

SELECT SQL_CALC_FOUND_ROWS main.info_id AS info_id,info_datemodified,info_uid,caldav_name,info_subject,info_status,info_owner,GROUP_CONCAT(attendees.account_id) AS info_responsible,GROUP_CONCAT(attendees.info_res_attendee) AS info_cc FROM egw_infolog main LEFT JOIN egw_infolog_users ON main.info_id=egw_infolog_users.info_id LEFT JOIN egw_infolog_users attendees ON main.info_id=attendees.info_id AND attendees.info_res_deleted IS NULL WHERE ( (info_owner=17 OR (egw_infolog_users.account_id IN (’-1’,‘17’)) OR (egw_infolog_users.account_id IN (’-1’,‘17’) OR info_status = ‘offer’ AND info_owner=17) AND (info_access=‘public’ OR info_owner=17)) AND NOT (info_status IN (‘template’,‘nonactive’,‘archive’)) AND info_type=‘task’ AND info_datemodified>1678956815 ) GROUP BY main.info_id ORDER BY info_datemodified DESC LIMIT 0,500

SELECT FOUND_ROWS()

(repeat ad infinitum with 100% CPU usage, until eGroupware is stopped with “sudo systemctl restart docker”).

User #17 is unable to sync any calendar until eGroupware is restarted.
When any other user starts to sync his/her infolog, eGroupware enters the same endless loop, with different user ID and different info_datemodified.

When I submit the SQL query manually, there is an empty result set (i.e. no recent changes).

I tried to track the error down to Thunderbird, but eGroupware does not send any infolog-related HTTP reply to Thunderbird at all, only calendar-related requests and replies are logged in the log which I have enabled in eGroupware-Preferences-CalDAV/CardDAV Sync-Logging.

Thank you very much. Log is attached (redacted for privacy reasons, but all relevant items should still be there)

Mozilla!5.0 (X11; Linux x86_64; rv:102.0) Gecko!20100101 Thunderbird!102.10.0.log.txt1 (252,3 KB)

Thank you for looking into this. I’ll give another, more complex try:
21:02 - starting Thunderbird, initial sync (automatically)
21:03 - initiating manual sync (this does not create any entry in the server-side log, sorry)
21:03-21:08: 100% cpu load on the server
21:08 - some component (nginx?) obviously runs into a timeout, stopping the endless loop
21:09 - initiating manual sync again, no entry in the server-side log
21:09-21:10: 100% cpu load on the server
21:10 - creating an infolog item (caption: “test-item”) via web interface, this breaks the loop, cpu load on the server drops
21:11 - initiating manual sync again. This sync is successful immediately

I guess that the success of the final sync is because there is something to sync, and the endless loop is an error when there is nothing to sync.
Mozilla!5.0 (X11; Linux x86_64; rv:102.0) Gecko!20100101 Thunderbird!102.10.0.log.txt (28,0 KB)

After ten minutes of testing, that looks like it does solve the issue. Thank you!