LiveObjects SYNC sequence tests

[VeskeR]

This PR is based on #1891, please review it first.

Adds LiveObjects integration tests for functionality introduced in #1887, #1890 and #1891.

NOTE: next Live Objects tests are expected to fail until https://ably.atlassian.net/browse/DTP-982 is fixed:

• builds state object tree from STATE_SYNC sequence on channel attachment
• LiveMap is initialized with initial value from STATE_SYNC sequence
• LiveMaps can reference the same object in their keys

Failure is due to missing state object in STATE_SYNC sequence for a map which has zero values.

Summary by CodeRabbit

Summary by CodeRabbit

• New Features

  • Introduced a size() method to the LiveMap class for retrieving the size of the data map.
  • Added a new live_objects_helper dependency for testing.
  • Implemented a LiveObjectsHelper class to manage LiveObjects state on channels.
  • Added a feature flag enableChannelState for new app creation.
  • Enhanced the test suite with a new helper function for channel options related to LiveObjects.

• Bug Fixes

  • Improved error handling in the test suite for scenarios when the LiveObjects plugin is absent.

• Documentation

  • Updated test suite structure for improved clarity and maintainability.

[coderabbitai]

Walkthrough

The changes in this pull request introduce several new functionalities and modifications across multiple files. A new size() method is added to the LiveMap class, which returns the size of the internal Map object. A new helper class, LiveObjectsHelper, is created to manage LiveObjects state, along with its associated methods. Additionally, a feature flag is added to the createNewApp function in the testapp_manager.js file, and the test suite is updated to incorporate these changes, including renaming functions and adding new test cases.

Changes

File Path	Change Summary
src/plugins/liveobjects/livemap.ts	- Method added: size(): number in class LiveMap
test/common/globals/named_dependencies.js	- New module added: live_objects_helper with paths for browser and Node.js
test/common/modules/live_objects_helper.js	- Class added: LiveObjectsHelper - Methods added: initForChannel, _createAndSetOnMap, _mapCreateOp, _mapSetOp, _counterCreateOp, _stateRequest - Exported singleton instance of LiveObjectsHelper
test/common/modules/testapp_manager.js	- Added feature flag enableChannelState in createNewApp function
test/realtime/live_objects.test.js	- Function renamed: LiveObjectsRealtime → RealtimeWithLiveObjects - Function added: channelOptionsWithLiveObjects - Expanded test cases and improved organization of tests

Possibly related PRs

• [DTP-952, DTP-953] Add base implementation for abstract LiveObject, concrete LiveMap/LiveCounter classes #1882: This PR introduces the LiveMap class, which is directly related to the size() method added to the LiveMap class in the main PR, as both modifications pertain to the same class and its functionality.

Suggested reviewers

• ttypic
• mschristensen
• owenpearson

🐰 In the garden, hopping free,
A new method blooms for all to see.
With helpers and flags, our code's a delight,
Testing the changes, we’ll code through the night!
So let’s celebrate with joy and cheer,
For every new feature that brings us near! 🌼

---

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?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 5

🧹 Outside diff range and nitpick comments (4)

src/plugins/liveobjects/livemap.ts (1)

63-65: LGTM! Consider adding readonly modifier.

The implementation of the size() method looks good. It correctly returns the size of the internal Map object, which is consistent with the class structure and provides a useful accessor for the map's size.

As a minor enhancement, consider adding the readonly modifier to the method signature:

readonly size(): number {
  return this._dataRef.data.size;
}

This would explicitly indicate that the method doesn't modify the object's state, which can be helpful for TypeScript users and potentially enable certain optimizations.

test/common/modules/testapp_manager.js (1)

136-136: LGTM! Consider adding a comment for clarity.

The addition of the 'enableChannelState' feature flag to the post_apps object is straightforward and appears to be intentional. This change will affect the configuration of newly created test apps, potentially enabling a new feature or behavior in the test environment.

Consider adding a brief comment explaining the purpose of this feature flag for future maintainers. For example:

// Enable channel state tracking for test apps
testData.post_apps.featureFlags = ['enableChannelState'];

This will help other developers understand the intention behind this configuration.

test/realtime/live_objects.test.js (2)

109-110: Ensure client is properly closed after test completion

At lines 109-110, a client is created but not explicitly closed after the test finishes:

const client = RealtimeWithLiveObjects(helper);

Ensure that the client is properly closed to prevent resource leaks. You can wrap the test logic with helper.monitorConnectionThenCloseAndFinish to manage the client lifecycle, which you've done correctly in other tests.

---

383-384: Clarify assertion message for nested counter's value

In lines 383-384, the assertion checks the value of a nested counter:

expect(counterFromReferencedMap.value()).to.equal(20, 'Check nested counter has correct value');

Consider enhancing the assertion message to specify which counter is being checked for clarity:

- expect(counterFromReferencedMap.value()).to.equal(20, 'Check nested counter has correct value');
+ expect(counterFromReferencedMap.value()).to.equal(20, 'Check that "counterFromReferencedMap" has the correct value');

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 0cdc7c7 and 3ee12cd.

📒 Files selected for processing (5)

• src/plugins/liveobjects/livemap.ts (1 hunks)
• test/common/globals/named_dependencies.js (1 hunks)
• test/common/modules/live_objects_helper.js (1 hunks)
• test/common/modules/testapp_manager.js (1 hunks)
• test/realtime/live_objects.test.js (3 hunks)

🧰 Additional context used

🪛 Biome

test/common/modules/live_objects_helper.js

[error] 1-1: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

---

[error] 171-171: The assignment should not be in an expression.

The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.

(lint/suspicious/noAssignInExpressions)

🔇 Additional comments (2)

test/common/globals/named_dependencies.js (1)

29-32: LGTM! New dependency added correctly.

The new live_objects_helper entry has been added consistently with the existing pattern. Both browser and Node.js paths are provided, which is in line with the structure of other entries in this file.

To ensure the correctness of the paths and the existence of the referenced module, please run the following verification script:

✅ Verification successful

Verification Successful: live_objects_helper module exists and paths are correct.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of the live_objects_helper module

# Test: Check if the file exists at the specified path
if [ -f "test/common/modules/live_objects_helper.js" ]; then
    echo "live_objects_helper.js file found at the specified path."
else
    echo "Error: live_objects_helper.js file not found at the specified path."
    exit 1
fi

# Test: Search for any imports or requires of the new module
echo "Searching for usage of live_objects_helper in the codebase:"
rg --type js "require\(['\"]test/common/modules/live_objects_helper['\"]" || echo "No usage found. This might be expected if the module is not yet used in tests."

Length of output: 554

src/plugins/liveobjects/livemap.ts (1)

63-65: Well-integrated addition to the LiveMap class

The size() method is a valuable addition to the LiveMap class. It's well-placed within the class structure and provides functionality that users would expect from a map-like object. This method enhances the usability of the LiveMap class by allowing easy access to the size of the underlying map, which is a common operation in many use cases.

The addition of this method aligns the LiveMap interface more closely with the standard JavaScript Map interface, which is a positive design choice for API consistency and user expectations.

[coderabbitai]

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (1)

test/realtime/live_objects.test.js (1)

123-138: LGTM: Verification of root object identification

This test case is a good addition:

1. It confirms that getRoot() returns a live object with the expected id "root".
2. It ensures the correct identification of the root object in the LiveObjects structure.

Note: The test uses a private API call (getObjectId()). While this is acceptable for testing, ensure that this method remains consistent across versions to maintain test stability.

Consider adding a comment explaining the use of the private API call, to prevent future confusion or unintended changes.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1510c81 and 4780a99.

📒 Files selected for processing (5)

• src/plugins/liveobjects/livemap.ts (1 hunks)
• test/common/globals/named_dependencies.js (1 hunks)
• test/common/modules/live_objects_helper.js (1 hunks)
• test/common/modules/testapp_manager.js (1 hunks)
• test/realtime/live_objects.test.js (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (3)

• src/plugins/liveobjects/livemap.ts
• test/common/globals/named_dependencies.js
• test/common/modules/testapp_manager.js

🧰 Additional context used

🪛 Biome

test/common/modules/live_objects_helper.js

[error] 1-1: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

---

[error] 170-170: The assignment should not be in an expression.

The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.

(lint/suspicious/noAssignInExpressions)

🔇 Additional comments (17)

test/common/modules/live_objects_helper.js (7)

3-6: LGTM: Clear module purpose and structure

The comment clearly describes the purpose of the LiveObjectsHelper, and the module definition with its dependency is correctly structured.

---

7-17: LGTM: Well-defined constants and utility function

The ACTIONS constant clearly defines the available operations, and the nonce function provides a simple way to generate unique identifiers. This structure enhances code readability and maintainability.

---

80-91: LGTM: Well-structured helper method

The _createAndSetOnMap method is well-structured and correctly handles the creation and setting of objects on maps. The use of separate state requests for creation and setting ensures atomicity of operations.

---

93-127: LGTM: Well-structured operation creation methods

The _mapCreateOp and _mapSetOp methods are well-structured and correctly use the ACTIONS constant to specify the action type. They provide a clear interface for creating map operations.

---

146-167: LGTM: Robust state request handling

The _stateRequest method is well-implemented. It correctly handles single object state requests, processes the response appropriately, and includes robust error handling. The extraction of the object ID from the response is a nice touch for convenience.

---

1-171: Overall assessment: Well-implemented helper with room for minor improvements

The LiveObjectsHelper class is well-implemented and achieves its purpose of creating and managing LiveObjects. The code is generally well-structured and includes appropriate error handling.

Key strengths:

1. Clear definition of actions and operations
2. Robust state request handling
3. Comprehensive implementation of the required state tree

Suggestions for improvement:

1. Remove the redundant 'use strict' directive
2. Refactor the initForChannel method for better readability
3. Ensure proper handling of zero count in counter creation
4. Simplify the module export statement

These improvements will enhance the maintainability and robustness of the code. Great job overall!

🧰 Tools

🪛 Biome

[error] 1-1: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

---

[error] 170-170: The assignment should not be in an expression.

The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.

(lint/suspicious/noAssignInExpressions)

---

1-1: ⚠️ Potential issue

Remove redundant 'use strict' directive

The 'use strict' directive is unnecessary in ES6 modules as they are strict by default. You can safely remove this line.

Apply this diff to remove the redundant directive:

-'use strict';

Likely invalid or redundant comment.

🧰 Tools

🪛 Biome

[error] 1-1: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

test/realtime/live_objects.test.js (10)

3-25: LGTM: Improved code organization and reusability

The changes in this section enhance the code structure:

1. Adding 'live_objects_helper' import improves modularity.
2. Renaming 'LiveObjectsRealtime' to 'RealtimeWithLiveObjects' increases clarity.
3. The new 'channelOptionsWithLiveObjects' function improves code reusability.

These modifications contribute to better maintainability of the test suite.

---

54-95: LGTM: Robust test for system behavior without LiveObjects plugin

This new test case is a valuable addition:

1. It verifies that the system doesn't break when receiving STATE_SYNC ProtocolMessages without the LiveObjects plugin.
2. It ensures that regular message subscriptions continue to function correctly.

This test enhances the overall robustness of the system by covering an important edge case.

---

100-106: LGTM: Verification of LiveObjects plugin integration

This test case is a good addition:

1. It confirms that the 'liveObjects' property returns a LiveObjects class instance when the plugin is properly integrated.
2. It uses the renamed 'RealtimeWithLiveObjects' function, maintaining consistency with earlier changes.

This test helps ensure the correct setup and integration of the LiveObjects plugin.

---

107-121: LGTM: Verification of getRoot() functionality

This test case is a valuable addition:

1. It confirms that getRoot() returns a LiveMap instance as expected.
2. It uses the new channelOptionsWithLiveObjects() function, promoting consistency in channel setup across tests.

This test helps ensure the correct behavior of a core LiveObjects functionality.

---

140-154: LGTM: Verification of empty root initialization

This test case is a valuable addition:

1. It confirms that getRoot() returns an empty root object when no state exists on a channel.
2. It verifies the correct initialization of LiveObjects on an empty channel.

This test helps ensure proper behavior in scenarios where no initial state is present, which is crucial for maintaining consistency in the LiveObjects system.

---

156-182: LGTM: Verification of getRoot() asynchronous behavior

This test case is an excellent addition:

1. It confirms that getRoot() waits for the initial STATE_SYNC to complete before resolving.
2. It uses nextTick to verify that getRoot() doesn't resolve prematurely.

This test is crucial for ensuring the correct asynchronous behavior of getRoot(), which is essential for maintaining data consistency in the LiveObjects system.

---

184-208: LGTM: Verification of efficient getRoot() behavior post-synchronization

This test case is a valuable addition:

1. It confirms that getRoot() resolves immediately when the STATE_SYNC sequence is completed.
2. It uses nextTick to verify the timing of the resolution, ensuring it happens on the next tick after synchronization.

This test is important for ensuring efficient behavior of getRoot() after the initial synchronization, which can impact the performance of applications using LiveObjects.

---

210-286: LGTM: Comprehensive verification of getRoot() behavior during re-synchronization

This test case is an excellent addition:

1. It confirms that getRoot() waits for subsequent STATE_SYNC sequences to finish before resolving.
2. It simulates a new synchronization sequence by injecting STATE_SYNC messages, providing a realistic test scenario.
3. It verifies the correct state of the root object after the new synchronization sequence.

This test is crucial for ensuring the reliability of LiveObjects during re-synchronization scenarios, which can occur in real-world applications due to network issues or other factors.

---

288-447: LGTM: Comprehensive testing of LiveObjects state building and initialization

These test cases are excellent additions:

1. They verify the correct building of the state object tree from the STATE_SYNC sequence.
2. They ensure proper initialization of LiveCounter and LiveMap with initial values.
3. They confirm that LiveMaps can reference the same object in their keys.

These tests are crucial for ensuring the correct behavior and structure of LiveObjects state in various scenarios. They provide comprehensive coverage of the LiveObjects functionality, which is essential for maintaining the reliability and consistency of the system.

---

450-464: 🛠️ Refactor suggestion

Consider using RealtimeWithLiveObjects for comprehensive testing

While the test logic is correct, there's an opportunity for improvement:

1. The test currently uses helper.AblyRealtime() instead of RealtimeWithLiveObjects(helper).
2. A previous comment suggested using RealtimeWithLiveObjects for more comprehensive testing of LiveObjects functionality.

To ensure full coverage of LiveObjects functionality, consider updating the test as follows:

- const client = helper.AblyRealtime();
+ const client = RealtimeWithLiveObjects(helper);

This change will ensure that the test is using the Realtime client with the LiveObjects plugin, providing a more comprehensive test of the LiveObjects state modes.

[coderabbitai]

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)

test/realtime/live_objects.test.js (1)

450-464: Consider using RealtimeWithLiveObjects for comprehensive testing

This test case effectively verifies that a channel can be attached with LiveObjects state modes. However, as suggested in a previous comment, consider updating the test to use RealtimeWithLiveObjects(helper) instead of helper.AblyRealtime(). This change would ensure that the test covers the full LiveObjects functionality.

Here's how you could modify the test:

- const client = helper.AblyRealtime();
+ const client = RealtimeWithLiveObjects(helper);

This modification would provide more comprehensive coverage of the LiveObjects functionality in this test case.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 4780a99 and 42c9d5c.

📒 Files selected for processing (1)

• test/realtime/live_objects.test.js (3 hunks)

🧰 Additional context used

🔇 Additional comments (8)

test/realtime/live_objects.test.js (8)

3-25: Improved code organization and readability

The changes in this section enhance the overall structure of the test file:

1. Addition of 'live_objects_helper' import
2. Renaming 'LiveObjectsRealtime' to 'RealtimeWithLiveObjects'
3. Introduction of 'channelOptionsWithLiveObjects' function

These modifications make the code more descriptive and easier to understand.

---

54-95: Good addition: Handling STATE_SYNC without LiveObjects plugin

This new test case is a valuable addition. It ensures that the system remains stable when receiving STATE_SYNC ProtocolMessages, even without the LiveObjects plugin. This improves the robustness of the system and prevents potential issues in mixed environments.

---

100-121: Comprehensive basic LiveObjects functionality tests

These new test cases provide good coverage for the basic functionality of LiveObjects:

1. Verifying the liveObjects property on the channel
2. Checking that getRoot() returns a LiveMap instance

The consistent use of the renamed RealtimeWithLiveObjects function is noted and appreciated.

---

123-286: Thorough coverage of getRoot() scenarios

The new test cases for getRoot() are comprehensive and well-structured. They cover important scenarios such as:

1. Returning an empty root when no state exists
2. Waiting for initial STATE_SYNC to complete
3. Resolving immediately when STATE_SYNC is already completed
4. Handling subsequent STATE_SYNC messages

These tests significantly improve the reliability and robustness of the LiveObjects functionality.

---

288-339: Comprehensive state object tree building test

This test case thoroughly verifies the correct building of the state object tree from the STATE_SYNC sequence. It checks:

1. The correct number of keys in the root object
2. The existence and correct types of counters and maps
3. The correct number of keys in nested maps

This level of detail ensures that the state synchronization process is working as expected.

---

341-363: Thorough LiveCounter initialization test

This test case effectively verifies the correct initialization of LiveCounter objects with values from the STATE_SYNC sequence. It covers multiple scenarios:

1. Empty counter
2. Counter with initial value
3. Referenced counter

This ensures that LiveCounter objects are properly synchronized across different use cases.

---

365-409: Comprehensive LiveMap initialization test

This test case provides excellent coverage for LiveMap initialization:

1. Verifies empty map initialization
2. Checks referenced map with nested counter
3. Tests various data types (string, empty string, bytes, empty bytes, number, zero, boolean)
4. Verifies nested map structures

The thoroughness of this test ensures robust handling of different data types and structures in LiveMap objects.

---

411-447: Effective test for LiveMap object references

This test case effectively verifies that LiveMaps can reference the same object in different parts of the structure:

1. Checks that a nested counter in a map is the same instance as a counter on the root
2. Verifies that a nested map is the same instance as a map on the root

This ensures consistency and proper object referencing within the LiveObjects structure.