Closed utkarshtopinkatti051 closed 3 months ago
Please make a PR with a test case, then I can fix that otherwise I cannot start working on it.
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.
@utkarshtopinkatti051 I am still interested in this. Can you make a PR with a failing test case to reproduce the problem?
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.
Is there any updates on this?
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.
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.
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:
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