[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.

[tamas646]

Okay, so I lived along with this issue for so long by emptying the trash bin if an error occurred.

But now I've found out how to successfully reproduce it. 🎉

Environment:

Nextcloud server version: 31.0.5 (I used the one that I installed several years ago)
DBMS: MariaDB 10.11.11
Tasks app version: 0.16.1
DAVx5 version: 4.4.10-ose (404100004)
App to manage tasks on Android: either OpenTasks (1.4.2) or Tasks.org (14.6.2)

Preparation:

1. Create 2 empty lists through the NC Tasks app:

• List A (id: 64)
• List B (id: 65)

SELECT id, uri, calendarid, uid, deleted_at FROM oc_calendarobjects WHERE calendarid = 64 OR calendarid = 65 ORDER BY id;
# Empty set

2. Configure DAVx5 to synchronize these 2 lists to the Android app (OpenTasks or Tasks.org).
3. Set DAVx5 tasks synchronization to Manual (so it only syncs when we hit sync :))
4. Disable automatic cron job and all other clients that were configured to sync with NC (just to be sure nothing interferes)

Steps to reproduce:

1. Create Task 1 in List A through the Android app

2. Sync with DAVx5

   Results of SQL query:

   

3. Move Task 1 to List B through the Android app

4. Sync with DAVx5
   Now it appears in the trash bin.

   Results of SQL query:

   

5. Move Task 1 back to List A through the Android app

6. Sync with DAVx5
   Now there are 2 items in the trash bin. The database starts becoming messy at this point I think.

   Results of SQL query:

   

7. Move Task 1 back to List B through the Android app

8. Sync with DAVx5
   Now there are 3 items in the trash bin.

   Results of SQL query:

   

9. Move Task 1 back to List A again through the Android app

10. Sync with DAVx5
    And now there are 4 items in the trash bin, which is good.

    Results of SQL query:

    

The problem starts here. From now I am no longer able to delete this item either through DAVx5 (item reappears after next sync) or through the NC Tasks web UI. The latter gives me HTTP 403 Forbidden with the following error message:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
  <s:message>A calendar object with URI d46f8a04-95eb-4813-8f61-5bc8934fab5e-deleted.ics already exists in calendar 64, therefore this object can't be moved into the trashbin</s:message>
</d:error>

If I tries to delete it through DAVx5:

1. Delete Task 1 from List A through the Android app

2. Sync with DAVx5
   No error and no change in database:

   Results of SQL query:

   

Temporary solution

1. Empty the trash bin

   Results of SQL query:

   

2. Delete the task (and sync)

   Results of SQL query:

   

3. Empty the trash bin again

   Results of SQL query:

   

PS

I think that the fact that I could reproduce the issue with new empty lists excludes the possibility that it's a glitch in my database (which I believed so far), so I guess it must be a bug in the code (or design). But it's only my perception, of course anything could happen. :)

I hope I provided enough info. If not, I'm happy to help. :)

[tamas646]

@joshtrichards can you please reopen this issue?
I no longer have the permission to do it.