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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃悰 Avoid mutating milestone snapshots when building from ops #651

Merged
merged 1 commit into from
May 14, 2024

Conversation

alecgibson
Copy link
Collaborator

At the moment, we directly pass our milestone snapshot to ot.applyOps(), which mutates the snapshot.

In most Production-grade implementations of the MilestoneDb, this is fine, since mutating the in-memory Snapshot will have no effect on the underlying database representation.

However, this does break the MemoryMilestoneDb (eg in tests).

In order to fix this, and generally be defensive (eg if db adapters decide to implement an in-memory cache), this change clones the snapshot before calling ot.applyOps() on it.

@coveralls
Copy link

coveralls commented May 14, 2024

Coverage Status

coverage: 97.345%. remained the same
when pulling 1683efa on milestone-mutation
into a5c19b9 on master.

Copy link
Contributor

@ericyhwang ericyhwang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable. _buildSnapshotFromOps is only called for milestone retrieval, so overall extra performance overhead should be negligible.

Just had one suggestion for an extra comment to clarify the new test case, go ahead and merge afterwards.

next();
},
function(next) {
connection.fetchSnapshot('books', 'mocking-bird', 3, next);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a comment indicating that this test case is making sure the client-facing connection.fetchSnapshot doesn't cause an in-place mutation to the stored milestone snapshot returned by the internal milestoneDb.getMilestoneSnapshot.

It took me a bit to realize where the mutation would formerly have occurred.

At the moment, we directly pass our milestone snapshot to
`ot.applyOps()`, which [mutates the snapshot][1].

In most Production-grade implementations of the `MilestoneDb`, this is
fine, since mutating the in-memory `Snapshot` will have no effect on the
underlying database representation.

However, this does break the `MemoryMilestoneDb` (eg in tests).

In order to fix this, and generally be defensive (eg if db adapters
decide to implement an in-memory cache), this change clones the snapshot
before calling `ot.applyOps()` on it.

[1]: https://github.com/share/sharedb/blob/a5c19b986d65c93abbc9ed11f7a25c0dbaf0788c/lib/ot.js#L172
@alecgibson alecgibson merged commit 8ba276c into master May 14, 2024
7 checks passed
@alecgibson alecgibson deleted the milestone-mutation branch May 14, 2024 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants