Duplicated entries in the oc_vcategory table cause favourite tags to not be permanently deleted

[MorrisJobke]

Steps to reproduce

1. Select some random files as favourite
2. Web interface shows a correct removal
3. Reloading the browser makes the favourite tags to be showed back. Checking the database tables will show duplicated entries for the same user in the oc_vcategory table (see below).
   After manually removing the duplicated entries in the oc_vcategory table and the corresponding ones in oc_vcategory_to_object, favourite tags are permanently deleted.

Expected behaviour

Favourite tags should be permanently deleted and no duplicated entries for the same user in the oc_vcategory table should exist.

Actual behaviour

See above

Server configuration

ownCloud version: 8.1.4

mysql> select * from oc_vcategory; 
+----+----------+-------+------------------+ 
| id | uid | type | category | 
+----+----------+-------+------------------+ 
| 2 | user857 | files | _$!<Favorite>!$_ | 
| 3 | user857 | files | _$!<Favorite>!$_ | 
+----+----------+-------+------------------+ 
2 rows in set (0.00 sec) 

mysql> select * from oc_vcategory_to_object; 
+-------+------------+-------+ 
| objid | categoryid | type | 
+-------+------------+-------+ 
| 4472 | 2 | files | 
| 4484 | 3 | files | 
+-------+------------+-------+ 
2 rows in set (0.00 sec)

cc @pako81

[MorrisJobke]

The deletion of tags is covered in #12858

@PVince81 Have you seen the above duplication in the past?

[PVince81]

I suspect a concurrency issue: two parallel calls noticing that the tag did not exist so it created it...

We should probably lock the file before working on tags, and maybe also add a unique key.

[PVince81]

The ticket #12858 is actually only for the relations, not the tags themselves.

[PVince81]

You should be able to manually delete one of the tags in the database including its relationship as a quickfix.

Is that only a single occurrence of the duplication ?

[pako81]

@PVince81 they've only noticed one single occurence of the duplication since now but Customer does not exclude that some other end users are also affected by this as they did have not the chance to check

[bboule]

Guys next steps on this?

[PVince81]

Is that only a single occurrence of the duplication or is it easily reproducible ?

@MorrisJobke ^ for severity

[MorrisJobke]

@PVince81 When are those tags added? Isn't it checked to only add it once? And why is there no unique constraint in that table?

[nickvergessen]

And why is there no unique constraint in that table?

fix it ;)

[PVince81]

@MorrisJobke I think it should, but if two processes do the check first, then insert at the same time, the check for both will see that the tag wasn't set. Locking might help.

[nickvergessen]

Locking might help.

No, just favorite two different files at the same time.

What might help is unique key and/or insert if not exists

[ghost]

@bboule @MorrisJobke moving to 9.1 unless there's an objection

[MorrisJobke]

@bboule @MorrisJobke moving to 9.1 unless there's an objection

cc @pako81

00004316

[pako81]

yes, ok for 9.1

[PVince81]

@pako81 has this happened again recently ?

[pako81]

No, no similar issues have been reported to us recently AFAIK

/cc @cdamken

[PVince81]

moving to backlog for another time

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[stale]

This issue has been automatically closed.