Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
txchen opened this issue Oct 9, 2022 · 7 comments
Labels
bug Something isn't working

Comments

@txchen
Copy link

txchen commented Oct 9, 2022

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

, 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
Copy link
Author

txchen commented Oct 9, 2022

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

@mdouchement
Copy link
Owner

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
Copy link
Owner

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
Copy link
Owner

mdouchement commented Nov 12, 2022

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
Copy link

michael-fritzsch commented Dec 9, 2022

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
Copy link
Owner

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:

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
Copy link

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.

@mdouchement mdouchement added the bug Something isn't working label Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants