Closed window9u closed 2 weeks ago
The recent updates significantly enhance error handling and introduce new features for document management in the system. Key changes include capturing errors during document instantiation and providing a method to set an initial document value at creation. These improvements increase the robustness and flexibility of document handling, ensuring that errors are caught early and improving overall usability.
Files | Change Summary |
---|---|
api/converter/converter_test.go |
Improved error handling in test cases by capturing errors from document creation. |
pkg/document/change/change.go |
Added RemoveOperations method to clear operations in the Change struct. |
pkg/document/document.go |
Updated Options struct to include InitialDoc field and modified New function for error handling. |
pkg/document/document_test.go |
Enhanced error handling in test cases for document creation. |
pkg/document/gc_test.go |
Added error handling during document instantiation in garbage collection tests. |
server/packs/packs.go |
Updated PushPull function to improve synchronization of client-server states. |
Objective | Addressed | Explanation |
---|---|---|
Provide an interface to set the initial value when creating a document (#669) | β |
π Hop along, my friend, so spry and bright,
With new features and checks, weβll code with delight.
Documents now stand tall, no errors in sight,
In our garden of code, all blooms look just right! πΌβ¨
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
This PR addresses a simple issue of adding an initializing interface. However, considering scenarios where a document needs to be initialized and attached while an existing document is already present, this PR has expanded in scope.
initialDoc
Change
Therefore, I suggest applying only the first part of this issue (#669) in this PR and addressing the second part after resolving issue #805. It is better to consider this approach when dealing with this issue.
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #669
Special notes for your reviewer:
Handling Client Rollback with Snapshot
To handle failures, we need to implement Client's Rollback.
In the current implementation, there is no rollback for invalid changes. If the initial document fails during attachment, we can roll back the changes by resetting the root, as there was no document initially.
However, we need to consider the following situation:
Solution: Always applying a Snapshot from the server. By applying a snapshot, we can handle rollbacks without changing the Client code, allowing the existing logic to proceed as intended.
Handling Failure
Change
Possible Solutions:
Marking Invalid Changes: Add a special marker to the change message, such as
invalid_init
.invalid_init
on both the server and client sides.Server Deletion of Invalid Changes: The server can remove operations related to invalid changes.
I chose option 2 for simpler implementation. We could mitigate this by adding a
bool valid
field to the Change, but I'm not certain this approach is correct. Additionally, if there are no plans to check for invalid changes, adding a field for this feature may be excessive.Does this PR introduce a user-facing change?:
Additional documentation:
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor