Delete tag sync problem - sync_conflict and the web client will keep retrying

[txchen]

To repro

• Add a new tag in browser A, then delete the tag.
• login and sync from browser B
• Go back to browser A, refresh
• The web app will start to POST v1/items endlessly

Example request:

{"items":[{"content_type":"Tag","created_at_timestamp":0,"created_at":"2022-10-09T06:28:08.438Z","deleted":true,"updated_at_timestamp":0,"updated_at":"2022-10-09T20:36:46.083Z","uuid":"970fb9d9-abaf-4671-b81b-cfc7b5ed03e8"}],"sync_token":"MjoxNjY1MzQ4OTY3MjY5Njg3NTI3","limit":150,"api":"20200115"}

response:

{
    "retrieved_items": [],
    "saved_items": [],
    "conflicts": [
        {
            "server_item": {
                "uuid": "970fb9d9-abaf-4671-b81b-cfc7b5ed03e8",
                "created_at": "2022-10-09T06:28:08.438Z",
                "updated_at": "2022-10-09T20:36:50.337854034Z",
                "user_uuid": "fc44c92b-0b70-4e18-954b-dfdcc4b5323a",
                "items_key_id": "",
                "content": "",
                "content_type": "Tag",
                "enc_item_key": "",
                "deleted": true
            },
            "type": "sync_conflict"
        }
    ],
    "sync_token": "MjoxNjY1MzQ4OTY3Mjk3MDk1MTA2",
    "cursor_token": ""
}

Looks like it is from https://github.com/mdouchement/standardfile/blob/e925f8a577fb1dd29cfe0e27fc7f65ecd609c0a4/internal/server/service/sync_20190520.go#L147, I am not familiar with the protocol, so not sure if this is by design. But basically this makes the web app sending requests crazily and waste a lot of resource on both client and server side.

[txchen]

When this happens, I can sign out and sign in again, and this will stop.

[mdouchement]

I don't use tags so I never had this issue. It may be a change in the API. It would be interesting to do this test on the standardnotes' server and compare the results.

[mdouchement]

I reproduced the issue

• Login in browser B
• Login in browser A
• Add a tag in browser A
• Wait synchro with browser B
• Remove the tag in browser A -> Infinite loop in brower A
• Click on the tag in browser B -> Infinite loop in brower B

I didn't reproduce this error on https://github.com/standardnotes/self-hosted, only POST /v1/items is used by the frontend.

I didn't see the root cause yet. It seems there are new fields in the items' payload. This issue needs to dig in the official project https://github.com/standardnotes/server/tree/main/packages/syncing-server/src

[mdouchement]

In fact, when an item (tag, note, whatever) is deleted by setting "deleted":true, there is an infinite loop. Only one client is enough to trigger this issue.

[michael-fritzsch]

I am also regularly hit by this issue. I noticed two scenarios, where this happens:

1. Deleting a note or a tag (as described above)
2. Doing some work with notes. When I then log out of the app to stop that POST firing on /v1/items, I get a message in the app that one note has not been synced and if I would like to log out anyway. (This happens regularly, but I couldn't figure out yet how to reproduce this behavior.)

It seems as if the client cannot sync one item and therefore gets in the loop with POSTing to /v1/items to sync it over and over again. Maybe that was clear to you already, but I thought it might be helpful to share this observation here.

[mdouchement]

I tried several things to debug this issue but I don't figure out what happens here. The inputs/outputs seem OK compared to the official app, I didn't found anything in the source code (NodeJS is not very readable).

I tested several versions of desktop binaries and I found when the issue started:

• 3.20.0 KO
• 3.15.0-beta.2 KO
• 3.14.1 OK

The problem is that several releases use the same commit so it's impossible to see what happened between theses releases. Maybe some SNJS updates. It seems to be linked to the file storage feature.

[michael-fritzsch]

I might have found a new hint for the root cause of this issue (although not detailed enough to prove or even solve anything)...

Disclaimer first: I don't know anything about SNS/SQS and how they are used in an application architecture, especially within the frontend.

Standardnotes changed its self-hosting setup to be as follows:

• One docker image called "server", which contains the whole backend
• One localstack docker image, which provides a local version of AWS notification service SNS/SQS
• MySQL database
• Redis

I welcome this change compared to the previous resource-hungry setup and gave it a try. At first, I didn't configure localstack correctly, thus not having the SNS/SQS service running. In this stage, I saw the client POSTing several times per second to the backend and creating a new version of the same note each time. After fixing the localstack setup, this problem did not occur anymore.

I didn't do any detailed research about how SNS/SQS is used in the frontend. But as this behavior looked similar to this issue here, I suspect that it might relate somehow. As the Standardnote git-repo is somehow screwed, I couldn't search for any commit message including SNS/SQS.