calendar subscriptions are spread tenfold on other users as well filling database tables (oc_calendarobjects_props / oc_calendarchanges)

[githubcmb]

Steps to reproduce

1. As I do not know what componente is doing this (cron jobs?)
2. I cannot give a description how to get there. Sorry.

Expected behavior

For users on the server that do not have calendar sync enabled / configured, no large count of data should land in the db (calendar tables)

Actual behavior

Here are some DB queries and results to show what I am talking about.
Meanwhile NC has become almost unusable as it doing (unnecessary) things in the db, I presume.

(Query table sizes left out)
TABLE_NAME Size (MB)
oc_calendarobjects_props 1523.97
oc_calendarchanges 658.91
oc_filecache 36.70
oc_calendarobjects 8.67
oc_files_metadata 7.72
oc_cards 6.56
oc_activity 6.22
oc_files_metadata_index 0.92
oc_cards_properties 0.50
oc_files_trash 0.31
oc_bookmarks 0.30
oc_polls_votes_copy 0.30
oc_authtoken 0.20
oc_bookmarks_tree 0.20
oc_calendar_reminders 0.20

select calendarid, oc2.principaluri, oc2.displayname, oc2.uri, count(*)
from oc_calendarchanges oc1
left join oc_calendars oc2 on oc2.id=oc1.calendarid
group by calendarid

calendarid principaluri displayname uri count(*)
1 principals/users/user1 USER1 personal 999
4 principals/users/user2 default default 1346041
5 principals/users/user3 default default 2673908
6 principals/users/user4 User4 default 1347002
16 principals/users/user1 X+XX_gemeinsam xxx_gemeinsam 8727
17 principals/users/user1 Geburtstage geburtstage 321

--

select calendarid, oc2.principaluri, oc2.displayname, oc2.uri, count(*)
from oc_calendarobjects oc1
left join oc_calendars oc2 on oc2.id=oc1.calendarid
group by calendarid ;

calendarid principaluri displayname uri count(*)
1 principals/users/user1 USER1 personal 795
4 principals/users/user2 default default 36
5 principals/users/user3 default default 72
6 principals/users/user4 User4 default 448
16 principals/users/user1 X+XX_gemeinsam xxx_gemeinsam 3669
17 principals/users/user1 Geburtstage geburtstage 122

--

select calendarid, oc2.principaluri, oc2.displayname, uri, count(*)
from oc_calendarobjects_props oc1
left join oc_calendars oc2 on oc2.id=oc1.calendarid
group by calendarid ;

calendarid principaluri displayname uri count(*)
1 principals/users/user1 USER1 personal 1838
4 principals/users/user2 default default 2355854
5 principals/users/user3 default default 4011416
6 principals/users/user4 User4 default 2356733
16 principals/users/user1 X+XX_gemeinsam xxx_gemeinsam 6962
17 principals/users/user1 Geburtstage geburtstage 225

(NB: calendarobject have doubled since yesterday for user3 even after marking the calendar as deleted with occ dav:delete-calendar ...
I can add query results to find the culprit here.
Is there a way to really delete a calendar?

Calendar app version

6.5.1

CalDAV-clients used

iphone iOS26

Browser

Firefox 153

Client operating system

MacOS26.5.2

Server operating system

FreeBSD14.4p7

Web server

Apache

Database engine version

MariaDB

PHP engine version

PHP 8.4

Nextcloud version

32.0.13

Updated from an older installed version or fresh install

Updated from an older version

List of activated apps

Enabled:
  - activity: 5.0.0
  - admin_audit: 1.22.0
  - bookmarks: 16.2.4
  - calendar: 6.5.1
  - cloud_federation_api: 1.16.0
  - contacts: 8.3.16
  - dashboard: 7.12.0
  - dav: 1.34.2
  - federatedfilesharing: 1.22.0
  - federation: 1.22.0
  - files: 2.4.0
  - files_downloadlimit: 5.0.0
  - files_pdfviewer: 5.0.0
  - files_sharing: 1.24.1
  - files_trashbin: 1.22.0
  - firstrunwizard: 5.0.0
  - logreader: 5.0.0
  - lookup_server_connector: 1.20.0
  - nextcloud_announcements: 4.0.0
  - notifications: 5.0.0
  - oauth2: 1.20.0
  - password_policy: 4.0.0
  - photos: 5.0.0
  - polls: 9.1.4
  - privacy: 4.0.0
  - profile: 1.1.0
  - provisioning_api: 1.22.0
  - recommendations: 5.0.0
  - serverinfo: 4.0.0
  - settings: 1.15.1
  - sharebymail: 1.22.0
  - text: 6.0.2
  - theming: 2.7.0
  - twofactor_backupcodes: 1.21.0
  - updatenotification: 1.22.0
  - user_pwauth: 2.8.4
  - user_status: 1.12.0
  - viewer: 5.0.0
  - workflowengine: 2.14.0
Disabled:
  - app_api: 32.0.0 (installed 4.0.6)
  - bruteforcesettings: 5.0.0 (installed 2.4.0)
  - circles: 32.0.0 (installed 0.14.2)
  - comments: 1.22.0 (installed 1.20.1)
  - contactsinteraction: 1.13.1 (installed 1.9.0)
  - encryption: 2.20.0
  - files_external: 1.24.1
  - files_reminders: 1.5.0 (installed 1.3.0)
  - files_versions: 1.25.0 (installed 1.23.0)
  - notes: 5.0.2 (installed 5.0.2)
  - related_resources: 3.0.0 (installed 1.5.0)
  - support: 4.0.0 (installed 2.0.0)
  - survey_client: 4.0.0 (installed 1.8.0)
  - suspicious_login: 10.0.0
  - systemtags: 1.22.0 (installed 1.20.0)
  - twofactor_nextcloud_notification: 6.0.0
  - twofactor_totp: 14.0.0
  - user_ldap: 1.23.0
  - weather_status: 1.12.0 (installed 1.0.0)
  - webhook_listeners: 1.3.0 (installed 1.1.0-dev)

Nextcloud configuration

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cmb.ch"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/cmb.ch\/nc",
        "dbtype": "mysql",
        "version": "32.0.13.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "default_phone_region": "CH",
        "mail_smtpmode": "sendmail",
        "forcessl": true,
        "theme": "",
        "maintenance": false,
        "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
        "logfile_audit": "\/var\/log\/nextcloud\/nextcloud.audit.log",
        "loglevel": 1,
        "trashbin_retention_obligation": "auto, 14",
        "log.condition": {
            "users": [
                "cmb"
            ],
            "apps": [
                "files"
            ]
        },
        "updater.release.channel": "stable",
        "filelocking.enabled": true,
        "localstorage.allowsymlinks": true,
        "enable_previews": true,
        "preview_max_x": 384,
        "preview_max_y": 512,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "timeout": 0,
            "password": "***REMOVED SENSITIVE VALUE***"
        },
        "mysql.utf8mb4": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "maintenance_window_start": 1
    }
}

Web server error log

no obvious error in log

Log file

Browser log

Additional info

No response

[githubcmb]

user1 and user4 have each 1 (user4 2) subscriptions, from db:

id	uri	principaluri	displayname	refreshrate	calendarorder	calendarcolor	striptodos	stripalarms	stripattachments	lastmodified	synctoken	source
4	mwinterthurch	principals/users/user1	Karton+Zeitungen	PT0S	1	#AC7F5E	<null>	<null>	<null>	1775196430	1379334	http://m.winterthur.ch/appl/ical.php?apid=16225268&calhome=1066394
5	mwinterthurch-1	principals/users/user1	Grünabfuhr	PT0S	2	#CB30E0	<null>	<null>	<null>	1783054536	2706919	http://m.winterthur.ch/appl/ical.php?apid=2120564965&calhome=1066394
6	mwinterthurch	principals/users/user4	Karton+Papier	PT0S	0	#CB30E0	<null>	<null>	<null>	1781260158	1379159	http://m.winterthur.ch/appl/ical.php?apid=16225268&calhome=1066394

I found entries (in oc_calendarobjects) for calendarid (=4; user2 / =5; user3) and they all contain the displayname (eg "Karton+Zeitungen"), but user2 nor user3 does have a subscription.

Next; I try to find the corresponding data in super large tables oc_calendarobjects_props / oc_calendarchanges...Or find what exactlxy is there what should not be there.

[githubcmb]

I used the dav:delete-subscription command to get rid of also all those wrongly created entries.
It collided with the cron.php unfortunately, as I forgot about that, but after a deadlock and lock timeouts, finally it could delete all entries.
So the cron.php did add entries to 3 wrong users every 5 mins (when it ran). I have mysql logs and a copy from last week of the entire db if someone cares..