Skip to content

Synchronization test accuracy#1956

Draft
cursor[bot] wants to merge 1 commit intosync/snapshot-merge-protection-testsfrom
cursor/synchronization-test-accuracy-d341
Draft

Synchronization test accuracy#1956
cursor[bot] wants to merge 1 commit intosync/snapshot-merge-protection-testsfrom
cursor/synchronization-test-accuracy-d341

Conversation

@cursor
Copy link
Contributor

@cursor cursor bot commented Feb 11, 2026

Fixes for Sync Protocol Test and Scenario Bugs

Description

This PR addresses three identified bugs related to the synchronization protocol negotiation tests and simulation scenarios, ensuring test accuracy and coverage.

  1. Test divergence formula differs from actual implementation (bug_id: e2fde381-b08d-467e-95e1-75bea6036db9):

    • Motivation: The test preconditions in negotiation.rs used a symmetric divergence formula (1.0 - (min_count / max_count)), which differed from the asymmetric formula (abs_diff / remote.entity_count.max(1)) used in the actual calculate_divergence() function. This could lead to incorrect precondition assertions, especially when local > remote.
    • Change: Updated the divergence calculation in negotiation.rs (lines 131, 192, 429) to match the asymmetric formula used in protocol.rs, ensuring consistency between test assertions and production logic.
  2. Random seeds test uses fully deterministic identical inputs (bug_id: 24d031e8-3f0c-46fd-9dfd-bbf15ebc00b4):

    • Motivation: The test_protection_holds_across_random_seeds test in snapshot_merge_protection.rs iterated 100 times with different seeds but used Scenario::n_nodes_diverged(2), which is deterministic. This meant the test effectively ran the same assertion 100 times, providing a false sense of coverage.
    • Change: Modified the test to use RandomScenario::two_nodes_random(seed) for node generation, ensuring that each iteration uses genuinely varied node configurations based on the seed.
  3. Scenarios don't force named protocols via build_handshake (bug_id: ref1_963e2153-f958-4ee5-870b-8af5474d0f70):

    • Motivation: The build_handshake() method's max_depth estimation, based on entity_count, caused Scenario::force_bloom_filter() and Scenario::force_levelwise() to incorrectly trigger SubtreePrefetch (Rule 4) because the estimated depth was always > 3. This prevented proper testing of Rule 5 (BloomFilter) and Rule 6 (LevelWise).
    • Change: Added an optional handshake_depth_override field to SimNode and integrated it into build_handshake(). The force_bloom_filter() scenario now explicitly sets max_depth = 3 and force_levelwise() sets max_depth = 2, ensuring they correctly trigger their intended protocols.

Test plan

All changes are within the test and simulation crates. The existing cargo test suite was run locally and passed successfully, confirming that the fixes do not introduce regressions and that the tests now behave as intended. The changes improve the accuracy and coverage of existing tests.

Documentation update

No public or internal documentation updates are required as these changes are confined to test code and simulation utilities.


- Fix divergence formula in negotiation.rs tests to match actual
  calculate_divergence() implementation (abs_diff / remote.entity_count)
  instead of the incorrect symmetric formula (1.0 - min/max)

- Fix test_protection_holds_across_random_seeds to use
  RandomScenario::two_nodes_random(seed) instead of the deterministic
  Scenario::n_nodes_diverged(2), ensuring actual coverage variation

- Add handshake_depth_override to SimNode and set_handshake_depth() method
  to allow scenarios to control reported tree depth independently of
  entity count

- Update force_bloom_filter() and force_levelwise() scenarios to set
  appropriate depth overrides (3 and 2 respectively) to avoid triggering
  Rule 4 (SubtreePrefetch) when the scenarios are meant to test Rule 5
  (BloomFilter) and Rule 6 (LevelWise)
@cursor
Copy link
Contributor Author

cursor bot commented Feb 11, 2026

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
Learn more about Cursor Agents

@github-actions
Copy link

Your PR title does not adhere to the Conventional Commits convention:

<type>(<scope>): <subject>

Common errors to avoid:

  1. The title must be in lower case.
  2. Allowed type values are: build, ci, docs, feat, fix, perf, refactor, test.

Copy link

@meroreviewer meroreviewer bot left a comment

Choose a reason for hiding this comment

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

🤖 AI Code Reviewer

Reviewed by 3 agents | Quality score: 100% | Review time: 179.8s

💡 1 suggestions, 📝 1 nitpicks. See inline comments.


🤖 Generated by AI Code Reviewer | Review ID: review-4c8d6607

} else {
0.0
};
// Calculate divergence using the same formula as calculate_divergence():
Copy link

Choose a reason for hiding this comment

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

📝 Nit: Repeated divergence calculation could be extracted

The same divergence formula (abs_diff / remote.max(1)) is now repeated in three places (lines 131-136, 192-197, 429-433); a small helper function would improve DRY and make future formula changes easier.

Suggested fix:

Extract a `fn calculate_test_divergence(local_count: u64, remote_count: u64) -> f64` helper at module level.


/// Set the max_depth override for handshake generation.
///
/// This allows scenarios to control the reported tree depth independently
Copy link

Choose a reason for hiding this comment

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

💡 Consider documenting valid depth ranges

The set_handshake_depth method allows arbitrary u32 values, but the protocol rules only care about specific thresholds (>3 for Rule 4, 1-2 for Rule 6); documenting expected values would help future test authors.

Suggested fix:

Add a brief note like "/// Common values: 2 for LevelWise (Rule 6), 3 for BloomFilter (Rule 5), >3 for SubtreePrefetch (Rule 4)."

@github-actions
Copy link

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.

@github-actions github-actions bot added the Stale label Feb 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant