[Bug]: Cannot delete tasks (...object with URI ...-deleted.ics already exists...)

[tamas646]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I cannot delete some tasks through the webUI / dav sync.
Error message:
A calendar object with URI 02c84c0f-940b-4a61-a08c-7ea4cc5401df-deleted.ics already exists in calendar 10, therefore this object can't be moved into the trashbin

Steps to reproduce

Unfortunately I could not reproduce the issue with new tasks.
Only some older tasks (created in NC 25) which have been moved across multiple lists behave like this.

Expected behavior

The task should be deleted without any problem. :)

Installation method

None

Nextcloud Server version

26

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 22.2.3 to 23.0.1)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

Enabled:
  - activity: 2.18.0
  - calendar: 4.3.1
  - circles: 26.0.0
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contactsinteraction: 1.7.0
  - dashboard: 7.6.0
  - dav: 1.25.0
  - deck: 1.9.0
  - federatedfilesharing: 1.16.0
  - federation: 1.16.0
  - files: 1.21.1
  - files_external: 1.18.0
  - files_pdfviewer: 2.7.0
  - files_rightclick: 1.5.0
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.1
  - firstrunwizard: 2.15.0
  - forms: 3.2.0
  - logreader: 2.11.0
  - lookup_server_connector: 1.14.0
  - news: 21.1.0
  - nextcloud_announcements: 1.15.0
  - notes: 4.7.2
  - notifications: 2.14.0
  - oauth2: 1.14.0
  - onlyoffice: 7.8.0
  - password_policy: 1.16.0
  - photos: 2.2.0
  - privacy: 1.10.0
  - provisioning_api: 1.16.0
  - recommendations: 1.5.0
  - related_resources: 1.1.0-alpha1
  - serverinfo: 1.16.0
  - settings: 1.8.0
  - sharebymail: 1.16.0
  - support: 1.9.0
  - survey_client: 1.14.0
  - systemtags: 1.16.0
  - tasks: 0.14.5
  - text: 3.7.2
  - theming: 2.1.1
  - twofactor_backupcodes: 1.15.0
  - twofactor_nextcloud_notification: 3.6.0
  - twofactor_totp: 8.0.0-alpha.0
  - updatenotification: 1.16.0
  - user_status: 1.6.0
  - viewer: 1.10.0
  - weather_status: 1.6.0
  - workflowengine: 2.8.0
Disabled:
  - admin_audit: 1.16.0
  - bruteforcesettings: 2.6.0 (installed 2.2.0)
  - contacts: 4.0.4 (installed 4.0.4)
  - encryption: 2.14.0
  - maps: 1.0.0 (installed 1.0.0)
  - phonetrack: 0.7.4 (installed 0.7.4)
  - spreed: 15.0.4 (installed 15.0.4)
  - suspicious_login: 4.4.0
  - user_ldap: 1.16.0

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

Running the following query I got the result below:

SELECT id, uri, calendarid, uid, deleted_at FROM oc_calendarobjects WHERE calendarid = 10 AND uri like '%-deleted-deleted.ics';

I found the URIs above a little bit strange.

Maybe it's related to #34375.

In NC 25 I did not face any similar issue. (except the lack of ability to move tasks across lists)

[szaimen]

cc @raimund-schluessler I suppose this is a server issue and not a tasks issue, correct?

[raimund-schluessler]

cc @raimund-schluessler I suppose this is a server issue and not a tasks issue, correct?

Yes, this is a server issue. The Tasks app is not involved here.

It sounds like an issue that I thought was fixed. Tasks got moved into the trash bin and blocked moving them back into the list. Not sure why they cannot be deleted though.

[tamas646]

Update:

Emptying the task trash bin from the web UI fixed the problem. :)

Should I keep this issue opened?

[joshtrichards]

02c84c0f-940b-4a61-a08c-7ea4cc5401df-deleted.ics
[...]
SELECT id, uri, calendarid, uid, deleted_at FROM oc_calendarobjects WHERE calendarid = 10 AND uri like '%-deleted-deleted.ics';

The error comes from this bit of code:

server/apps/dav/lib/CalDAV/CalDavBackend.php

Lines 1507 to 1512 in 32e8605

	// Try to detect conflicts before the DB does
	// As unlikely as it seems, this can happen when the user imports, then deletes, imports and deletes again
	$newObject = $this->getCalendarObject($calendarId, $newUri, $calendarType);
	if ($newObject !== null) {
	throw new Forbidden("A calendar object with URI $newUri already exists in calendar $calendarId, therefore this object can't be moved into the trashbin");
	}

It would have been interesting to see the output of a query like SELECT id, uri, calendarid, uid, deleted_at FROM oc_calendarobjects WHERE uri LIKE '%02c84c0f-940b-4a61-a08c-7ea4cc5401df%'; (before the error cleared for you).

I found the URIs above a little bit strange.

I agree that the multiple deleted-deleted is weird.

We append the suffix -deleted to any entry we delete when we keep in in the caldav "trash can", but we also clean it up when we restore so not sure how it ended up duplicated in the uri:

server/apps/dav/lib/CalDAV/CalDavBackend.php

Lines 1492 to 1505 in 32e8605

	$pathInfo = pathinfo($data['uri']);
	if (!empty($pathInfo['extension'])) {
	// Append a suffix to "free" the old URI for recreation
	$newUri = sprintf(
	"%s-deleted.%s",
	$pathInfo['filename'],
	$pathInfo['extension']
	);
	} else {
	$newUri = sprintf(
	"%s-deleted",
	$pathInfo['filename']
	);
	}

server/apps/dav/lib/CalDAV/CalDavBackend.php

Lines 1547 to 1555 in 32e8605

	public function restoreCalendarObject(array $objectData): void {
	$this->cachedObjects = [];
	$this->atomic(function () use ($objectData) {
	$id = (int) $objectData['id'];
	$restoreUri = str_replace("-deleted.ics", ".ics", $objectData['uri']);
	$targetObject = $this->getCalendarObject(
	$objectData['calendarid'],
	$restoreUri
	);

Emptying the task trash bin from the web UI fixed the problem. :)
Should I keep this is

That makes sense (for the most part), given the error, but not sure how your old tasks ended up in that state. I'll close this since it's been a year and we haven't had further reports here. Don't hesitate to report if you see it come up anew.