chore: change streamingmode to exact for ranges with limits

[MasterPtato]

No description provided.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Nov 27, 2025 0:59am

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Nov 27, 2025 0:59am
rivet-inspector	Ignored	Preview		Nov 27, 2025 0:59am
rivet-site	Ignored	Preview		Nov 27, 2025 0:59am

[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(runtime): evict runners on SIGTERM, add periodic shutdown progress messages #3550
• fix(pb): implement events and commands for actor wfs #3543
• fix: make all uses of protocol handle v4 <-> v3 #3528
• fix(pb): simplify runner wf #3483
• fix(gas): fix loop forgotten bug due to concurrency #3482
• 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
• chore: change streamingmode to exact for ranges with limits #3476 👈 (View in Graphite)
• fix(gas): optimize loops #3475
• fix: parallelize publish signal awaits #3523
• chore: fix diff between ee, fix plural api query params #3524
• 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]

Code Review - PR #3476

Summary

This PR correctly changes StreamingMode::WantAll to StreamingMode::Exact for all range queries that specify an explicit limit parameter. This is an appropriate optimization based on FoundationDB's streaming mode semantics.

Positive Findings

Correctness ✅

• The change is semantically correct according to the FoundationDB documentation in engine/packages/universaldb/src/options.rs:193:
  • Exact: "A row limit must be specified if this mode is used"
  • WantAll: "Client intends to consume the entire range"
• All modified locations specify explicit limits via limit: Some(...), making Exact the appropriate choice

Performance ✅

• Using Exact mode when you know the exact limit avoids unnecessary data transfer and batching overhead
• This is particularly beneficial for the affected use cases:
  • download_instances.rs: Downloading a specific count of instances
  • recover_keys_chunk: Recovery operations with fixed batch sizes
  • list_names.rs: List operations with pagination limits
  • debug.rs: Debug queries checking for existence (limit: Some(1))

Consistency ✅

• I verified that remaining WantAll usages don't specify limits, confirming this PR caught all the relevant cases
• The change is applied consistently across 6 files

Code Quality ✅

• One minor improvement in engine/packages/epoxy/src/workflows/replica/setup.rs:443-449: The struct fields were reordered (mode and limit moved before end and begin), which improves readability by grouping the critical query parameters together

Potential Considerations

Testing

• Consider verifying that the behavior is unchanged for these operations, particularly:
  • download_instances - ensure instance downloads still work correctly
  • recover_keys_chunk - ensure recovery operations complete successfully
  • The debug queries with limit: Some(1) - these should be fast lookups

While the semantic change is minimal (both modes should return the same results when a limit is specified), the different batching behavior could theoretically expose edge cases.

Documentation

• The PR title and description are minimal. Consider adding context about why this change improves performance (reducing unnecessary batching overhead when exact limits are known).

Verdict

LGTM - This is a well-targeted performance optimization with no apparent bugs or issues. The change correctly applies StreamingMode::Exact to all range queries with explicit limits, which aligns with FoundationDB best practices.

The only suggestion is to ensure adequate test coverage for the affected code paths, though this appears to be a low-risk refactoring.

[claude]

PR Review: Change StreamingMode to Exact for ranges with limits

Summary

This PR correctly updates FoundationDB range queries to use StreamingMode::Exact instead of StreamingMode::WantAll when a specific limit is set. This aligns with FoundationDB best practices.

Code Quality ✅

Correctness: The changes are semantically correct. According to FoundationDB documentation:

• WantAll: For consuming entire ranges with no specific limit
• Exact: For queries with a specific row limit that should be delivered in a single batch

All modified queries have explicit limits set, making Exact the appropriate choice.

Affected Files:

1. epoxy/src/replica/messages/download_instances.rs - Fetching log entries with req.count limit
2. epoxy/src/workflows/replica/setup.rs - Scanning key instances with count limit (also reordered fields for consistency)
3. gasoline/src/db/kv/debug.rs - Two debug queries with limit: Some(1)
4. namespace/src/ops/runner_config/list.rs - Listing configs with input.limit
5. pegboard/src/ops/actor/list_names.rs - Listing actor names with input.limit
6. pegboard/src/ops/runner/list_names.rs - Listing runner names with input.limit

Performance Considerations ⚡

Positive Impact: Using Exact mode should provide:

• More predictable performance for limited queries
• Better resource utilization (single batch vs. progressive fetching)
• Reduced overhead since the client explicitly knows it wants exactly N rows

Potential Issues 🔍

Minor Note - Field Reordering: In epoxy/src/workflows/replica/setup.rs:445-450, the fields were reordered:

// Before
begin: begin_key,
end: end_key,
mode: StreamingMode::WantAll,
limit: Some(count as usize),

// After  
mode: StreamingMode::Exact,
limit: Some(count as usize),
end: end_key,
begin: begin_key,

While this works fine (fields use named syntax), it's inconsistent with other files in the PR. Consider keeping the original field order for consistency, though this is purely stylistic.

Missing Coverage 🔎

I noticed a few files still using WantAll without limits (which is correct), but wanted to flag these for awareness:

• pegboard/src/ops/runner/get.rs:109 - No limit (correct as-is)
• pegboard/src/ops/actor/hibernating_request/list.rs:42 - No limit (correct as-is)
• pegboard-serverless/src/lib.rs:79 - No limit (correct as-is)

These are intentionally not changed and should remain WantAll.

Test Coverage 📝

Recommendation: While the changes are straightforward, it would be beneficial to verify that:

1. Queries still return the expected number of results
2. Behavior is unchanged when the actual data size is less than the limit
3. Behavior is unchanged when the actual data size exceeds the limit

You could run the affected package tests:

cargo test --package epoxy --package gasoline --package namespace --package pegboard

Security Concerns 🔒

No security issues identified.

Verdict ✅

Approved - This is a good optimization that aligns query patterns with FoundationDB best practices. The changes are minimal, focused, and semantically correct.

Optional: Consider keeping consistent field ordering in setup.rs to match the other files.

Great work on identifying and fixing this pattern across the codebase!

[claude]

Code Review

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact for all range queries that have explicit limit parameters. This is the correct optimization based on the FoundationDB documentation.

Positives

1. Correct Use of StreamingMode::Exact
According to the StreamingMode enum documentation in engine/packages/universaldb/src/options.rs:192, Exact mode is for clients that have "passed a specific row limit and wants that many rows delivered in a single batch."

All modified queries have explicit limits, making Exact the appropriate mode:

• download_instances.rs: limit of req.count
• recover_keys_chunk: limit of count
• gasoline/debug.rs: limit of 1 (two occurrences)
• namespace_runner_config_list: limit of input.limit
• pegboard_actor_list_names: limit of input.limit
• pegboard_runner_list_names: limit of input.limit

2. Performance Improvement
Using Exact mode eliminates unnecessary overhead from the adaptive batching behavior of WantAll, since these queries know exactly how many rows they need upfront.

3. Consistency
The changes align with existing patterns in the codebase. For example, engine/packages/pegboard/src/workflows/actor/runtime.rs:210 already uses StreamingMode::Exact with limit: Some(1).

Minor Observations

1. Field Reordering in setup.rs
In engine/packages/epoxy/src/workflows/replica/setup.rs:445-450, the fields were reordered (mode/limit/end/begin instead of begin/end/limit/mode). While this doesn't affect functionality, it deviates from the struct definition order per range_option.rs:25-35. This is purely stylistic and not a blocker.

2. Test Coverage
No tests were found specifically for these query functions. While the change is straightforward and correct, consider adding integration tests that verify:

• Queries return exactly limit rows when more are available
• Queries return fewer than limit rows when fewer exist
• Pagination works correctly with the new streaming mode

Security and Correctness

• No security concerns identified
• No potential bugs introduced
• Changes are backward compatible

Verdict

Approved

This is a clean optimization that correctly uses FoundationDB's Exact streaming mode for queries with known limits. The change improves performance without affecting correctness.

---

Review generated with Claude Code

[claude]

Code Review

Summary

This PR correctly changes StreamingMode::WantAll to StreamingMode::Exact for range queries that specify a limit. This is the right change according to FoundationDB's documentation.

Analysis

What's the difference?
According to the StreamingMode enum documentation in engine/packages/universaldb/src/options.rs:

• WantAll: "Client intends to consume the entire range and would like it all transferred as early as possible."
• Exact: "The client has passed a specific row limit and wants that many rows delivered in a single batch."

When a query specifies limit: Some(n), using StreamingMode::Exact is the semantically correct choice since we know exactly how many rows we want.

Findings

✅ Correct Changes (6 files):

• engine/packages/epoxy/src/replica/messages/download_instances.rs - ✓
• engine/packages/epoxy/src/workflows/replica/setup.rs - ✓ (also reordered fields, which is fine)
• engine/packages/gasoline/src/db/kv/debug.rs (2 instances) - ✓
• engine/packages/namespace/src/ops/runner_config/list.rs - ✓
• engine/packages/pegboard/src/ops/actor/list_names.rs - ✓
• engine/packages/pegboard/src/ops/runner/list_names.rs - ✓

⚠️ Missed Instance:
There's at least one more instance that should be changed:

engine/packages/gasoline/src/db/kv/mod.rs:

tx.get_ranges_keyvalues(
    universaldb::RangeOption {
        mode: StreamingMode::WantAll,  // <- Should be Exact
        limit: Some(1),
        ..(&pending_signal_subspace).into()
    },
    // ...
)

Recommendations

1. Update the missed instance in engine/packages/gasoline/src/db/kv/mod.rs for consistency
2. Consider doing a final sweep to ensure all WantAll + limit combinations are caught

Performance & Correctness

✅ Performance: Using Exact with a limit is more efficient than WantAll because it tells FoundationDB to deliver exactly the requested number of rows in a single batch, avoiding unnecessary data transfer.

✅ Correctness: The change is semantically correct and aligns with FoundationDB best practices.

✅ No Breaking Changes: This is purely an optimization/correctness fix with no API changes.

Overall Assessment

This is a good cleanup PR that improves query efficiency. Once the missed instance is addressed, this will be ready to merge.

Action Items:

• Update engine/packages/gasoline/src/db/kv/mod.rs to use StreamingMode::Exact where it has limit: Some(1)

[claude]

Code Review

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact for FoundationDB range queries that have explicit limits. This is a good performance optimization.

Positive Observations

✅ Correct optimization: According to the FoundationDB documentation, when you have a specific row limit, StreamingMode::Exact is the appropriate mode to use. The comment in the options enum states that Exact mode is for when "The client has passed a specific row limit and wants that many rows delivered in a single batch" and "A row limit must be specified if this mode is used."

Using Exact with explicit limits is more efficient than WantAll because:

• WantAll transfers data early and potentially over-fetches
• Exact delivers the precise number of rows requested in a single batch

✅ Comprehensive coverage: The PR correctly identifies and updates all instances where mode: StreamingMode::WantAll is used with an explicit limit: Some(...). I verified that the remaining WantAll usages in the codebase do not have explicit limits, which is correct.

✅ Consistent pattern: All 6 changed files follow the same pattern - queries with known limits that should use Exact mode.

Minor Observations

📝 Code organization (epoxy/workflows/replica/setup.rs:446): The field order was changed, moving mode and limit before end and begin. While this doesn't affect functionality, consider maintaining consistent field ordering across similar code blocks for readability. Most other changes kept the original order.

Testing Recommendations

While this is a performance optimization that shouldn't change behavior, consider:

• Running existing integration tests to ensure queries return the same results
• Performance testing to validate the expected improvements, especially for the list operations in namespace and pegboard packages

Verdict

Approved - This is a solid optimization that correctly applies FoundationDB best practices. The changes are straightforward and well-targeted.

[claude]

Code Review

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact in 6 locations where range queries have explicit limit values set. This is a sensible optimization.

Analysis

What this change does:

• StreamingMode::WantAll tells FoundationDB to fetch as many results as it reasonably can in each network call, assuming the client will consume all results.
• StreamingMode::Exact tells FoundationDB that the limit parameter is the exact number of results needed, so it should not over-fetch beyond this limit.

Why this is correct:
All 6 modified locations have explicit limit values:

• download_instances.rs: limit: Some(req.count as usize)
• setup.rs: limit: Some(count as usize)
• debug.rs (2 places): limit: Some(1)
• list.rs and both list_names.rs: limit: Some(input.limit)

Using Exact mode when a limit is specified is the recommended approach per FoundationDB documentation. It prevents over-fetching data that will be discarded, reducing unnecessary network overhead and memory usage.

Consistency check:
The codebase correctly uses different streaming modes for different patterns:

• StreamingMode::Exact - for queries with explicit limits (this PR)
• StreamingMode::Iterator - for paginated iteration with manual cursor control (e.g., list_for_ns.rs)
• StreamingMode::WantAll - for queries where all results are needed without a limit (e.g., get.rs, hibernating_request/list.rs)

Minor Note

In setup.rs, the field ordering was also reordered (mode and limit moved up). This is purely cosmetic and has no functional impact, but maintains consistency with how the struct fields are typically written in the codebase.

Verdict

✅ LGTM - This is a correct and beneficial optimization. The change improves efficiency by using the appropriate streaming mode when limits are specified.

🤖 Generated with Claude Code

[claude]

PR Review: chore: change streamingmode to exact for ranges with limits

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact in 6 locations where a limit is specified on range queries. This is a correct optimization.

✅ Code Quality & Best Practices

The change is correct. According to the FDB documentation in universaldb/src/options.rs:

• WantAll: "Client intends to consume the entire range and would like it all transferred as early as possible"
• Exact: "The client has passed a specific row limit and wants that many rows delivered in a single batch"

Using WantAll with a limit is semantically incorrect - WantAll tells FDB to optimize for transferring the entire range, but a limit indicates you only want a subset. Exact is the appropriate mode when you know exactly how many rows you need.

✅ Performance Considerations

This change should improve performance:

1. Exact mode tells FDB to return exactly the requested number of rows in a single batch
2. WantAll may over-fetch data that gets discarded due to the limit, wasting network bandwidth and database resources
3. The batching strategy with Exact is optimized for the known row count

✅ Files Changed

All changes are consistent and follow the same pattern:

• epoxy/src/replica/messages/download_instances.rs - limit from req.count
• epoxy/src/workflows/replica/setup.rs - limit from count
• gasoline/src/db/kv/debug.rs (2 locations) - limit of 1
• namespace/src/ops/runner_config/list.rs - limit from input.limit
• pegboard/src/ops/actor/list_names.rs - limit from input.limit
• pegboard/src/ops/runner/list_names.rs - limit from input.limit

✅ Completeness Check

I verified there are no remaining WantAll usages with limits in the codebase. The remaining WantAll usages (in pegboard/src/ops/runner/get.rs and pegboard/src/ops/actor/hibernating_request/list.rs) don't specify limits, so they're correctly using WantAll to consume entire ranges.

Minor Observation

In epoxy/src/workflows/replica/setup.rs, the field order was rearranged:

// Before
begin: begin_key,
end: end_key,
limit: Some(count as usize),
mode: StreamingMode::WantAll,

// After
mode: StreamingMode::Exact,
limit: Some(count as usize),
end: end_key,
begin: begin_key,

This doesn't affect functionality but is inconsistent with the other files in this PR (which maintain begin/end first). Consider keeping the field order consistent across all files, though this is a very minor nit.

Verdict

LGTM ✅ - This is a straightforward and correct optimization. No bugs or security concerns.

[claude]

Code Review

Summary

This PR correctly changes StreamingMode::WantAll to StreamingMode::Exact for FoundationDB range queries that specify explicit limits. This is a well-targeted performance optimization that aligns with FoundationDB best practices.

Analysis

Why This Change is Correct:

According to the FoundationDB documentation in engine/packages/universaldb/src/options.rs:187-202:

• WantAll: "Client intends to consume the entire range and would like it all transferred as early as possible"
• Exact: "The client has passed a specific row limit and wants that many rows delivered in a single batch. A row limit must be specified if this mode is used"

When a query specifies limit: Some(n), using StreamingMode::Exact is semantically correct and more efficient because:

1. It tells FoundationDB to deliver exactly the requested number of rows in a single batch
2. Avoids potential over-fetching and unnecessary batching overhead of WantAll
3. Reduces network round-trips when the exact result count is known

Files Changed (All Correct ✅)

File	Limit	Use Case
epoxy/src/replica/messages/download_instances.rs:42	req.count	Downloading specific number of instances
epoxy/src/workflows/replica/setup.rs:446	count	Key recovery chunking
gasoline/src/db/kv/debug.rs:521,673	Some(1)	Debug existence checks
namespace/src/ops/runner_config/list.rs:67	input.limit	Paginated config listing
pegboard/src/ops/actor/list_names.rs:43	input.limit	Paginated actor listing
pegboard/src/ops/runner/list_names.rs:42	input.limit	Paginated runner listing

All modified locations specify explicit limits, making Exact the appropriate choice.

Code Quality ✅

Consistency Check: I verified that remaining WantAll usages in the codebase do not specify limits, confirming this PR correctly identified all relevant instances. For example:

• pegboard/src/ops/runner/get.rs:109 - No limit (correct to use WantAll)
• pegboard/src/workflows/runner.rs:901 - No limit (correct to use WantAll)

Minor Note - Field Ordering: In epoxy/src/workflows/replica/setup.rs:445-450, the struct fields were reordered (mode/limit moved before end/begin). While this doesn't affect functionality, it creates a slight inconsistency with other files in the PR. Consider using consistent field ordering for maintainability, though this is purely stylistic.

Performance Impact ⚡

Positive: This change should improve performance by:

• Reducing network overhead with single-batch delivery
• Preventing over-fetching of data
• More efficient resource usage when limits are known upfront
• Particularly beneficial for small-limit queries like the limit: Some(1) cases in debug.rs

Testing Recommendations 📝

While this is a straightforward optimization that shouldn't change behavior, consider:

1. Running existing integration tests to ensure no regressions:

   cargo test -p epoxy -p gasoline -p namespace -p pegboard

2. Verifying the change works correctly when:
   • Actual data size is less than the limit
   • Actual data size exceeds the limit
   • Pagination continues to work as expected

Security & Correctness 🔒

• ✅ No security concerns identified
• ✅ No potential bugs introduced
• ✅ Backward compatible change

Verdict

LGTM ✅ - This is a solid optimization that correctly applies FoundationDB best practices. The changes are minimal, focused, and semantically correct. Great work identifying this pattern across the codebase!

---

🤖 Review generated with Claude Code

[claude]

Code Review - APPROVE

This PR correctly changes StreamingMode::WantAll to StreamingMode::Exact in 6 locations where range queries have explicit limits.

Positive Aspects

1. Correct Usage Pattern - According to FoundationDB documentation, Exact mode is specifically designed for cases where a specific row limit is provided, while WantAll mode is for consuming entire ranges. Since all modified queries have explicit limits, using Exact is the appropriate choice.

2. Consistent Changes - All 6 modifications follow the same pattern.

3. Performance Improvement - Exact mode should be more efficient when limits are known upfront, as it avoids the overhead of batch size escalation.

4. Code Quality - The changes are minimal and surgical.

Minor Observations

1. Style Inconsistency - In epoxy/src/workflows/replica/setup.rs:446, the field order was changed. While functionally equivalent, this reordering was not necessary.

2. Test Coverage - Consider adding integration tests to verify both modes return the same results.

3. Documentation - Consider adding inline comments explaining when to use Exact vs WantAll.

Security and Correctness

No security concerns, no changes to business logic, no potential for data loss.

Performance

Using Exact with known limits should improve performance by reducing roundtrips and requesting exactly the needed data upfront.

Recommendation

APPROVE - The core change is correct and beneficial.

Follow-up suggestions:

• Document the pattern in CLAUDE.md
• Add integration tests
• Audit remaining WantAll usage

Nice optimization!

[claude]

Code Review

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact for range queries that have a limit parameter. This is a good optimization that aligns with FoundationDB best practices.

---

✅ Positive Findings

1. Correct Usage of StreamingMode::Exact

According to the FoundationDB documentation (from the code in options.rs):

• StreamingMode::Exact: "The client has passed a specific row limit and wants that many rows delivered in a single batch. A row limit must be specified if this mode is used."
• StreamingMode::WantAll: "Client intends to consume the entire range and would like it all transferred as early as possible."

Since all the modified code paths have explicit limit: Some(...) parameters, using Exact is the correct choice. This tells FoundationDB to return exactly that many rows in a single batch, which is more efficient than WantAll when you know the exact count you need.

2. Consistent Pattern

The changes follow a consistent pattern across all 6 files:

• engine/packages/epoxy/src/replica/messages/download_instances.rs - downloading specific count of instances
• engine/packages/epoxy/src/workflows/replica/setup.rs - recovering key chunks with specific count
• engine/packages/gasoline/src/db/kv/debug.rs - checking for existence with limit=1
• engine/packages/namespace/src/ops/runner_config/list.rs - listing with pagination
• engine/packages/pegboard/src/ops/actor/list_names.rs - listing with pagination
• engine/packages/pegboard/src/ops/runner/list_names.rs - listing with pagination

3. Performance Improvement

Using Exact mode when you have a specific limit should:

• Reduce network overhead by requesting exactly what you need
• Improve query planning on the database side
• Reduce memory usage on the client side

4. No Breaking Changes

The change is purely an optimization. The functional behavior remains the same - the queries will still return the same results, just more efficiently.

---

🔍 Observations

1. Code Reordering in one file

In engine/packages/epoxy/src/workflows/replica/setup.rs, the fields in RangeOption were reordered:

// Before
begin: begin_key,
end: end_key,
limit: Some(count as usize),
mode: StreamingMode::WantAll,

// After
mode: StreamingMode::Exact,
limit: Some(count as usize),
end: end_key,
begin: begin_key,

While this doesn't affect functionality (field order doesn't matter in struct initialization), it's inconsistent with the other files. Consider keeping the original field order for consistency.

2. Comparison with Iterator Mode

I noticed that other parts of the codebase (e.g., list_for_ns.rs files) use StreamingMode::Iterator with manual limit checking in a loop:

mode: StreamingMode::Iterator,
// ... in loop:
if results.len() >= input.limit {
    break;
}

The files you've modified correctly use Exact instead, which is better since they can rely on the database limit directly without manual loop breaking.

---

✨ Suggestions

Minor: Consider Updating Similar Patterns

There may be other places in the codebase using WantAll with limits that could benefit from this optimization. You might want to search for other instances that haven't been updated yet.

However, this is outside the scope of this PR and can be addressed separately if needed.

---

📊 Test Coverage

I don't see explicit tests for these specific code paths in the diff. Since this is a performance optimization without functional changes, the existing integration tests should cover correctness. However, consider:

1. Running the existing test suite to ensure no regressions
2. If there are performance benchmarks, running them to validate the improvement

---

🎯 Final Verdict

LGTM ✅

This is a solid optimization that:

• Correctly applies FoundationDB best practices
• Improves performance for limited range queries
• Maintains backward compatibility
• Shows good understanding of the database API

The only minor suggestion is to keep consistent field ordering in the struct initialization, but this is purely stylistic and doesn't block approval.

---

Recommendation: Approve and merge after confirming tests pass.

[claude]

Code Review

This is a well-focused PR that improves FoundationDB query performance by using the appropriate StreamingMode.

Summary

The PR changes StreamingMode::WantAll to StreamingMode::Exact for range queries that have explicit limits. This is the correct optimization based on FoundationDB's documentation.

Positive Observations

✅ Correct Performance Optimization: According to the FoundationDB documentation (from engine/packages/universaldb/src/options.rs:187-193):

• WantAll: "Client intends to consume the entire range"
• Exact: "Client has passed a specific row limit and wants that many rows delivered in a single batch"

When a query specifies limit: Some(count), using Exact mode is semantically correct and more efficient.

✅ Comprehensive Coverage: The PR updates 6 files across multiple packages:

• epoxy (replica message handling and workflow setup)
• gasoline (KV debug utilities)
• namespace (runner config listing)
• pegboard (actor and runner name listing)

✅ Consistent Pattern: All changes follow the same pattern - switching from WantAll to Exact when limit: Some(...) is present.

Potential Issues Found

⚠️ Incomplete Coverage: The grep search reveals there's at least one more location that should likely be updated but was missed:

// engine/packages/gasoline/src/db/kv/mod.rs:1919-1923
tx.get_ranges_keyvalues(
    universaldb::RangeOption {
        mode: StreamingMode::WantAll,  // ⚠️ Should be Exact
        limit: Some(1),
        ..(&pending_signal_subspace).into()
    },
    Serializable,
)

This appears in engine/packages/gasoline/src/db/kv/mod.rs:1921 and follows the exact same pattern (limit with WantAll).

Minor Observation

In engine/packages/epoxy/src/workflows/replica/setup.rs, the field ordering was changed (mode moved before begin/end). This is fine but not strictly necessary for the functional change.

Recommendations

1. Add the missing location: Update engine/packages/gasoline/src/db/kv/mod.rs:1921 to use StreamingMode::Exact as well.

2. Consider a comprehensive audit: Run a search for all instances of mode: StreamingMode::WantAll with limit: Some to ensure no other cases were missed.

3. Testing: Ensure integration tests cover these query paths to verify the performance improvement doesn't introduce behavioral changes.

Verdict

The core change is correct and beneficial. However, the PR appears incomplete - there's at least one more location that should be updated. I recommend adding the missing update to engine/packages/gasoline/src/db/kv/mod.rs:1921 before merging.

---

Review generated with assistance from Claude Code

[claude]

PR Review: Change StreamingMode to Exact for ranges with limits

Summary

This PR changes StreamingMode::WantAll to StreamingMode::Exact for range queries that specify a limit. This is a correct and appropriate optimization based on FoundationDB's streaming mode semantics.

Key Findings

✅ Correct Usage: According to the StreamingMode documentation in engine/packages/universaldb/src/options.rs:192:

• Exact: The client has passed a specific row limit and wants that many rows delivered in a single batch
• WantAll: Client intends to consume the entire range and would like it all transferred as early as possible

When a specific limit is set, Exact is the semantically correct mode since the client knows exactly how many rows they want.

Changes Reviewed

All 6 changed locations follow the same pattern - range queries with explicit limits:

1. epoxy/replica/messages/download_instances.rs:42 - limit: Some(req.count as usize)
2. epoxy/workflows/replica/setup.rs:446 - limit: Some(count as usize)
3. gasoline/db/kv/debug.rs:521 - limit: Some(1) (checking existence)
4. gasoline/db/kv/debug.rs:673 - limit: Some(1) (checking existence)
5. namespace/ops/runner_config/list.rs:67 - limit: Some(input.limit)
6. pegboard/ops/actor/list_names.rs:43 - limit: Some(input.limit)

Code Quality Assessment

Strengths:

• ✅ Semantically correct - aligns mode with FoundationDB best practices
• ✅ Consistent pattern - all changes follow the same principle
• ✅ Performance improvement - reduces unnecessary data transfer when exact row count is known
• ✅ Existing codebase already uses this pattern (see pegboard/workflows/actor/runtime.rs:204)

Observations:

• One file (epoxy/workflows/replica/setup.rs) also reordered fields, which is a harmless formatting change
• The pattern is already established in the codebase for similar use cases

Recommendations

No blocking issues identified. The changes are:

1. Technically correct per FoundationDB documentation
2. Consistent with existing patterns in the codebase
3. Performance-positive (avoid over-fetching data)

Minor Note

The field reordering in epoxy/workflows/replica/setup.rs:445-449 (moving mode and limit before end and begin) is stylistic but harmless. Consider keeping field ordering consistent across the codebase in future changes.

---

Recommendation: ✅ APPROVE - This is a good optimization that correctly applies FoundationDB streaming modes.

---

🤖 Generated with Claude Code

[claude]

Code Review

Summary

This PR correctly changes StreamingMode::WantAll to StreamingMode::Exact for range queries that specify a limit. This is the appropriate fix based on FoundationDB's streaming mode semantics.

---

Analysis

What the change does:
According to the FoundationDB documentation (from engine/packages/universaldb/src/options.rs:187-202):

• StreamingMode::Exact: The client has passed a specific row limit and wants that many rows delivered in a single batch. A row limit must be specified if this mode is used.
• StreamingMode::WantAll: Client intends to consume the entire range and would like it all transferred as early as possible.

When you specify a limit, you are explicitly requesting a specific number of rows, which makes Exact the semantically correct mode.

Files changed:

1. epoxy/src/replica/messages/download_instances.rs - Fetching specific count of instances
2. epoxy/src/workflows/replica/setup.rs - Recovering key chunks with count limit
3. gasoline/src/db/kv/debug.rs (2 instances) - Debug queries checking for existence (limit: Some(1))
4. namespace/src/ops/runner_config/list.rs - Paginated list operation
5. pegboard/src/ops/actor/list_names.rs - Paginated list operation
6. pegboard/src/ops/runner/list_names.rs - Paginated list operation

All changes follow the same pattern: queries with explicit limits that were incorrectly using WantAll.

---

Findings

Missed Instance:
There is one more location with the same issue that was not included in this PR:

engine/packages/gasoline/src/db/kv/mod.rs:1919-1923
The code uses StreamingMode::WantAll with limit: Some(1), which should be Exact for consistency.

---

Code Quality

• Correctness: All changes are semantically correct
• Consistency: Changes follow existing patterns in the codebase
• Performance: Exact mode is more efficient for limited queries as it prevents unnecessary data transfer
• Style: Follows repository conventions

Minor note on setup.rs: The field reordering (mode before limit before end before begin) does not affect functionality, but the original order was more standard (begin/end/mode/limit). Not a blocker, just an observation.

---

Recommendations

1. Add the missed instance: Include the fix for gasoline/src/db/kv/mod.rs:1921
2. Consider a codebase audit: Search for any other WantAll + limit combinations to ensure completeness

---

Security and Performance

• No security concerns
• Performance improvement: Exact mode with limits is more efficient than WantAll because it:
  • Prevents over-fetching data from FoundationDB
  • Delivers results in a single batch (as documented)
  • Reduces network transfer and memory usage

---

Test Coverage

The changes are to internal FoundationDB query optimization and should not require new tests, but existing integration tests should cover these code paths. The modified functions are tested through:

• Replica download/recovery workflows (epoxy)
• Workflow debugging interfaces (gasoline)
• List operations for runners and actors (pegboard, namespace)

---

Verdict

LGTM with one suggestion: Excellent fix! Just add the missed instance in gasoline/src/db/kv/mod.rs:1921 for completeness.

---

Review generated by Claude Code