search

pubkey / rxdb

A fast, local first, reactive Database for JavaScript Applications https://rxdb.info/
https://rxdb.info/
Apache License 2.0
21.12k stars 1.03k forks source link

Checkpoint iteration strategy failing in simultaneous pull-push scenario. #5843

Closed utkarshtopinkatti051 closed 3 months ago

utkarshtopinkatti051 commented 5 months ago

Have you found a bug?

Yes! The checkpoint iteration strategy uses the "updatedAt" field of the latest pulled document, but in this case, the collection doesn't have this document. It's strange that this record is not logged in the conflict resolver either. Here are the steps to reproduce the issue:

  1. A document was updated on the server side while the client was in offline mode.
  2. The client updated the document while offline.
  3. The client came back online.
  4. The pull query was executed first, followed by the push query.

  5. The checkpoint iteration used the "updatedAt" field of the latest pulled document, but the collection still had the older document instead of the latest pulled document.

    References

    I further checked previously raised issue around this area but not sure if this is related to the one, I am facing. https://github.com/pubkey/rxdb/issues/5571#issue-2109073506

Rxdb Version used

-v15.16.0

pubkey commented 5 months ago

Please make a PR with a test case, then I can fix that otherwise I cannot start working on it.

stale[bot] commented 4 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. If you still have a problem, make a PR with a test case or to prove that you have tried to fix the problem. Notice that only bugs in the rxdb premium plugins are ensured to be fixed by the maintainer. Everything else is expected to be fixed by the community, likely you must fix it by yourself.

pubkey commented 3 months ago

@utkarshtopinkatti051 I am still interested in this. Can you make a PR with a failing test case to reproduce the problem?

stale[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon. Please update it or it may be closed to keep our repository organized. The best way is to add some more information or make a pull request with a test case. Also you might get help in fixing it at the RxDB Community Chat If you know you will continue working on this, just write any message to the issue (like "ping") to remove the stale tag.

lavaxun commented 3 months ago

Is there any updates on this?

pubkey commented 3 months ago

No updates on this. I tried to reproduce the problem but couldnt. If you have the same problem please make a PR with a test case, otherwise I will not be able to fix this.

utkarshtopinkatti051 commented 1 month ago

Hi everyone, I have identified the root cause of the issue we were experiencing. It appears that explicitly updating the updatedAt field from the client side was causing the problem. This was because the checkpoint iteration was working as expected, but the record that came from the backend was not persisting in RxDB due to the existing record in RxDB that had the updatedAt field explicitly added. This was interfering with the synchronization logic.

Although we were not sending the updatedAt field in the payload from the frontend, RxDB still had the record with the field, causing the issue. Therefore, I recommend that we avoid explicitly modifying the updatedAt field on the client side. This field is used for checkpoint iteration, and RxDB uses a change-detection algorithm that automatically triggers the mutation query when it detects any changes in the record's fields. Thank you for your attention.