chore(gas): add test for history with holes

[MasterPtato]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

4 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Nov 18, 2025 2:30am
rivet-inspector	Ignored	Preview		Nov 18, 2025 2:30am
rivet-site	Ignored	Preview		Nov 18, 2025 2:30am
rivetkit-serverless	Skipped			Nov 18, 2025 2:30am

[MasterPtato]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(pb): rewrite runner wf to handle batch signals #3480
• fix(gas): fix batch listen, fix history for graceful signal send in workflows #3479
• feat(gas): add batch listen #3478
• chore(gas): add test for history with holes #3477 👈 (View in Graphite)
• chore: change streamingmode to exact for ranges with limits #3476
• fix(gas): optimize loops #3475
• chore: rename retry -> hibernate in runner protocol #3473
• fix(udb): update backoff algo #3469
• chore: write/update docs #3468
• chore: add debug scripts #3467
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: Add test for history with holes

Summary

This PR adds two test cases (holes_in_coordinates and holes_in_coordinates2) to verify that the cursor correctly handles sparse coordinate sequences in workflow history. The tests validate important edge cases for the gasoline workflow engine's history traversal mechanism.

Code Quality ✅

Positives:

• Tests follow existing patterns and conventions in the file
• Clear test names that describe the scenario being tested
• Good use of the existing test macros (loc![], coord![])
• Tests are focused and verify specific behavior

Suggestions:

1. Test documentation: Consider adding doc comments to explain what "holes in coordinates" means and why this edge case matters:

   /// Tests that cursor correctly handles non-sequential coordinates in history.
   /// When coordinates have gaps (e.g., 1, 3, 6), the cursor should:
   /// - Navigate through existing events correctly
   /// - Continue from the last coordinate when reaching the end
   #[test]
   fn holes_in_coordinates() {

2. Test naming: The second test is named holes_in_coordinates2 which doesn't clearly communicate how it differs from the first. Consider a more descriptive name like holes_in_coordinates_insertion or insert_between_sparse_coordinates since it specifically tests insertion behavior.

3. Code duplication: Both tests create the exact same event structure. Consider extracting this into a helper function to reduce duplication:

   fn create_sparse_history() -> Arc<HashMap<Location, Vec<Event>>> {
       [(
           loc![],
           vec![
               Event {
                   coordinate: coord![1],
                   version: 1,
                   data: EventData::VersionCheck,
               },
               Event {
                   coordinate: coord![3],
                   version: 1,
                   data: EventData::VersionCheck,
               },
               Event {
                   coordinate: coord![6],
                   version: 1,
                   data: EventData::VersionCheck,
               },
           ],
       )]
       .into_iter()
       .collect::<HashMap<_, _>>()
       .into()
   }

Test Coverage ✅

The tests cover important scenarios:

• Test 1: Validates that the cursor navigates through sparse coordinates and continues correctly after the last event
• Test 2: Validates that insertions between sparse coordinates follow the correct cardinality rules (inserting 1.1 between coordinates 1 and 3)

Additional test cases to consider:

• Inserting between coordinates 3 and 6 (should be 3.1 based on the logic in current_location_for)
• Multiple insertions in the same gap
• Sparse coordinates at deeper nesting levels (e.g., coord![1, 1], coord![1, 5])

Potential Issues 🔍

No bugs detected. The tests correctly verify the expected behavior based on the Cursor implementation:

• Lines 43-66 in cursor.rs show coord_at() handles sparse coordinates by continuing from the last coordinate's head
• Lines 81-118 show current_location_for() uses cardinality comparison to determine insertion points
• The assertions align with this logic

Performance Considerations ✅

No performance concerns. These are unit tests with minimal overhead.

Security Concerns ✅

No security issues. Standard test code.

Adherence to CLAUDE.md Guidelines ✅

• ✅ Uses appropriate test structure
• ✅ Follows existing code patterns
• ✅ Uses structured event data correctly
• ⚠️ Could benefit from the testing guideline about piping output to /tmp/ and grepping, though for unit tests this may not be necessary

Recommendation

Approve with minor suggestions. The tests are solid and cover important edge cases. The suggested improvements (documentation, naming, deduplication) would enhance maintainability but aren't blocking issues.

---

🤖 Generated with Claude Code