Nextcloud-deck: Crash when moving card with custom tags between boards

[Enrico204]

Describe the bug
The app crashes when a card with a custom tag is moved between boards.

To reproduce
Issue is reproducible with an account from try.nextcloud.com:

• [ ] Yes
• [ ] No

Sorry I can't test it right now, I'll test it in few days

Steps to reproduce the behavior:

1. Create a new card in a board
2. Add a custom tag and add the tag to the card
3. Create a new board
4. Move the card to the new board

Expected behavior
The card is moved with the custom tag still attached to it.

Screenshots
N/a

Versions

• Nextcloud:
• Nextcloud Deck:
• Nextcloud Android:
• Nextcloud Android Deck: 1.13.1

Smartphone (please complete the following information):

• Device: Xiaomi Poco F1
• Android-Version: 10
• App-Store:
  
  
  
  • [ ] Google Play Store
  
  
  • [ ] Google Play Store (Beta channel)
  
  
  • [X] F-Droid
  
  
  • [ ] Huawei AppGallery
  
  

Are you using LDAP?

• [ ] Yes
• [X] No

Stacktrace

Full Crash:

App Version: 1.13.1
App Version Code: 1013001
App Flavor: fdroid

Files App Version Code: 30140190

---

OS Version: 4.9.247-perf-gc4c46f782703-ab4000128c1a(4000128c1a)
OS API Level: 29
Device: beryllium
Manufacturer: Xiaomi
Model (and Product): POCO F1 (beryllium)

---

android.database.sqlite.SQLiteConstraintException: FOREIGN KEY constraint failed (code 787 SQLITE_CONSTRAINT_FOREIGNKEY)
    at android.database.sqlite.SQLiteConnection.nativeExecuteForLastInsertedRowId(Native Method)
    at android.database.sqlite.SQLiteConnection.executeForLastInsertedRowId(SQLiteConnection.java:879)
    at android.database.sqlite.SQLiteSession.executeForLastInsertedRowId(SQLiteSession.java:790)
    at android.database.sqlite.SQLiteStatement.executeInsert(SQLiteStatement.java:88)
    at androidx.sqlite.db.framework.FrameworkSQLiteStatement.executeInsert(FrameworkSQLiteStatement.java:51)
    at androidx.room.EntityInsertionAdapter.insertAndReturnId(EntityInsertionAdapter.java:114)
    at it.niedermann.nextcloud.deck.persistence.sync.adapters.db.dao.JoinCardWithLabelDao_Impl.insert(JoinCardWithLabelDao_Impl.java:153)
    at it.niedermann.nextcloud.deck.persistence.sync.adapters.db.dao.JoinCardWithLabelDao_Impl.insert(JoinCardWithLabelDao_Impl.java:26)
    at it.niedermann.nextcloud.deck.persistence.sync.adapters.db.DataBaseAdapter.createJoinCardWithLabel(DataBaseAdapter.java:327)
    at it.niedermann.nextcloud.deck.persistence.sync.SyncManager.lambda$assignLabelToCard$41$SyncManager(SyncManager.java:1561)
    at it.niedermann.nextcloud.deck.persistence.sync.-$$Lambda$SyncManager$PNTWheRDo7L9Ue2SXZBBIeCZrgA.run(Unknown Source:8)
    at java.lang.Thread.run(Thread.java:919)

[desperateCoder]

Hi @Enrico204, thanks for your report!

Sorry I can't test it right now, I'll test it in few days

I think there is no need to test it in this case, I guess I know what is going on here. I'll investigate that these days and give you some feedback then.

Stay safe!

[desperateCoder]

@Enrico204 are you able to reproduce it reliably? If yes, would you mind installing a dev build with more verbose logging?

I think I know what the problem is (the label seems not being created locally - which is very strange), but I can't get into these problems on my machine somehow.

[Enrico204]

I can confirm that I can reproduce this issue every time. I've updated the app to 1.13.3, however the crash is still there (FYI).

Sometimes the card is duplicated, at least it seems to. I think that this might be related to a race condition between the client-to-server activity and the crash itself (the SQLite).

Also I just tried with the latest master (2b0b5b24) and the issue is still there. I tried to do some debugging but I'm not very familiar with the code and I found nothing right now. I'll try again as soon as I have some free time :-D

[desperateCoder]

I tried to do some debugging but I'm not very familiar with the code and I found nothing right now

That's nothing, we can't fix:
I'd start in the SyncManager:
https://github.com/stefan-niedermann/nextcloud-deck/blob/d9c089fa3783534d12b4eff3dc742079269821c9/app/src/main/java/it/niedermann/nextcloud/deck/persistence/sync/SyncManager.java#L1316

The problem itself shouldn't be there directly, I suspect it later on, when cloning the assigned tags (in our code we call them labels) and the assignments themselves:
https://github.com/stefan-niedermann/nextcloud-deck/blob/d9c089fa3783534d12b4eff3dc742079269821c9/app/src/main/java/it/niedermann/nextcloud/deck/persistence/sync/SyncManager.java#L1405-L1413

Especially have a look at Line 1412, that's the method where the app dies:
https://github.com/stefan-niedermann/nextcloud-deck/blob/d9c089fa3783534d12b4eff3dc742079269821c9/app/src/main/java/it/niedermann/nextcloud/deck/persistence/sync/SyncManager.java#L1478-L1501

I'd suspect, that in your case the creation of the label doesn't work somehow, so you'd enter the onError() case at line 1492. While it might look a little weird to assign the label in the error case you need to trust me, in most cases (afaik all cases except yours :wink:) that's the right thing to do. Then, the assignment would have been written here:

https://github.com/stefan-niedermann/nextcloud-deck/blob/d9c089fa3783534d12b4eff3dc742079269821c9/app/src/main/java/it/niedermann/nextcloud/deck/persistence/sync/SyncManager.java#L1558-L1579

The clue line here is 1562. That's the actual point, where we get the constraint violation. That means: Either the local cardId or the local labelId are not correct at this point, since there are foreign keys to those tabels. If you get to debug that far, you could look up your data directly in the database. Android Studio provides a nice database query tool, at least for virtual devices (never tried it with an actual phone tbh). Your queries would look something like this:

select * from Card where localId = ?;
select * from Label where localId = ?;

Hope this helps! If you got any further questions, just ask :smiley:

[desperateCoder]

@Enrico204 there's a small chance that we fixed that by accident. If you try the current master branch, it contains a fix of a (horribly dumb) mistake in a SQL-query. Take your time, just wanted to mention that.

[Enrico204]

You're right, I did a test with latest master and the problem is gone! :-) great! :tada:
Thanks :-)

[desperateCoder]

Always glad to help! 😊

Thanks for testing and reporting, this helps us a lot!

Stay safe!