Skip to content

Increase tooFarBlockRange threshold from 20k to 100k blocks#1322

Open
DZakh wants to merge 1 commit into
mainfrom
claude/magical-turing-vwjiy1
Open

Increase tooFarBlockRange threshold from 20k to 100k blocks#1322
DZakh wants to merge 1 commit into
mainfrom
claude/magical-turing-vwjiy1

Conversation

@DZakh

@DZakh DZakh commented Jun 15, 2026

Copy link
Copy Markdown
Member

Summary

Increases the tooFarBlockRange constant in FetchState.OptimizedPartitions from 20,000 to 100,000 blocks. This threshold determines when partition start blocks are considered "too far apart" and triggers partition merging logic.

Changes

  • Updated tooFarBlockRange constant from 20_000 to 100_000 in packages/envio/src/FetchState.res
  • Extracted tooFarBlockRange as a test constant in scenarios/test_codegen/test/lib_tests/FetchState_test.res to avoid hardcoding magic numbers
  • Updated all test assertions to reference the extracted constant instead of hardcoded values (20_001, 20_002)

Implementation Details

The tooFarBlockRange constant is used by the partition optimization logic to determine when event configs with distant start blocks should be merged together. By increasing this threshold from 20k to 100k blocks, the optimization becomes more conservative about merging partitions, allowing for better parallelization of data fetching across a wider block range before triggering merges.

The test changes maintain the same logical behavior while making the tests more maintainable by centralizing the threshold value.

https://claude.ai/code/session_01HxQeuZQ11GUAoBZdbFaDuW

Summary by CodeRabbit

  • Chores

    • Increased the partition merge optimization “too far” threshold from 20,000 to 50,000 blocks, reducing how often partitions are consolidated when their block-distance exceeds this limit.
  • Tests

    • Updated FetchState merge/partition test expectations to derive the “too far” threshold from the configured value instead of hard-coded numbers.

@coderabbitai

coderabbitai Bot commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

tooFarBlockRange in OptimizedPartitions is raised from 20_000 to 50_000, widening the block-distance window within which partitions remain eligible for merging. Tests are updated to source the threshold from the constant rather than hard-coded literals, keeping test expectations automatically in sync.

Changes

tooFarBlockRange threshold increase

Layer / File(s) Summary
tooFarBlockRange constant and test parameterization
packages/envio/src/FetchState.res, scenarios/test_codegen/test/lib_tests/FetchState_test.res
tooFarBlockRange is changed from 20_000 to 50_000 in OptimizedPartitions. Tests introduce a local tooFarBlockRange alias and replace all hard-coded block numbers in "far startBlocks" scenarios (startBlock, phase-1 comments, and expected mergeBlock values) with expressions derived from the constant.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Title check ⚠️ Warning The title states '100k blocks' but the raw_summary indicates the value was changed to '50_000', creating a discrepancy between the stated objective (100,000) and the actual implementation (50,000). Clarify whether the target threshold is 50,000 or 100,000 blocks and ensure the PR title accurately reflects the actual code change implemented.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


Comment @coderabbitai help to get the list of available commands and usage tips.

The grouping and merge threshold for dynamic contract partitions was a
fixed 20k blocks, which on sparse factories produced a large number of
partitions per registration wave. Raising it to 50k reduces the
partition count at the cost of fetching more discardable
pre-registration events per group.

https://claude.ai/code/session_01HxQeuZQ11GUAoBZdbFaDuW
@DZakh DZakh force-pushed the claude/magical-turing-vwjiy1 branch from 6f782f1 to 9ac7f31 Compare June 15, 2026 11:09

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/envio/src/FetchState.res`:
- Line 203: The tooFarBlockRange variable in FetchState.res is currently set to
50_000, but the PR summary states it should be increased to 100_000. Update the
tooFarBlockRange assignment to use 100_000 to match the stated PR objective,
ensuring the implementation is consistent with the documented intent.
- Line 203: The tooFarBlockRange threshold in FetchState.res has been increased
from 20,000 to 50,000 blocks. This changes the partition strategy for the E2E
test scenario: the 20,100 block gap between DC1 and DC2 no longer exceeds the
new threshold, so these contracts should now merge into a single partition
instead of remaining separate. Update the test assertion in E2E_test.res
(currently expecting partitions [("2", 5000), ("3", 25100), ("0", 25101)]) to
reflect the new merged partition outcome that results from this increased
threshold.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: de8d5b34-ce00-4534-9ff2-c20569b8f147

📥 Commits

Reviewing files that changed from the base of the PR and between 3f3c067 and 9ac7f31.

📒 Files selected for processing (2)
  • packages/envio/src/FetchState.res
  • scenarios/test_codegen/test/lib_tests/FetchState_test.res
🚧 Files skipped from review as they are similar to previous changes (1)
  • scenarios/test_codegen/test/lib_tests/FetchState_test.res

// If the value is off, it'll only result in
// quering the same block range multiple times
let tooFarBlockRange = 20_000
let tooFarBlockRange = 50_000

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Inconsistency between PR objectives and implementation.

The PR summary states the threshold is increased to 100,000, but the actual code shows 50,000. Please confirm which value is intended.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/envio/src/FetchState.res` at line 203, The tooFarBlockRange variable
in FetchState.res is currently set to 50_000, but the PR summary states it
should be increased to 100_000. Update the tooFarBlockRange assignment to use
100_000 to match the stated PR objective, ensuring the implementation is
consistent with the documented intent.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Find hardcoded references to old threshold values in E2E and other test files

# Search for hardcoded 20000 or 20_000 references
rg -n --type=res -C3 '20[_,]?000' scenarios/test_codegen/test/

# Search for comments mentioning tooFarBlockRange with specific values
rg -n --type=res -C3 'tooFarBlockRange.*\(20' scenarios/test_codegen/test/

# Look for the specific E2E test case mentioned in context
rg -n --type=res -A10 -B5 'Gap.*25099.*4999.*20100' scenarios/test_codegen/test/

Repository: enviodev/hyperindex

Length of output: 147


🏁 Script executed:

#!/bin/bash
# Search for .res files in the test scenarios directory
fd -e res scenarios/test_codegen/test/ | head -20

# Search for the specific gap calculation mentioned in the review
rg -n 'Gap.*25099.*4999.*20100' scenarios/test_codegen/test/ --no-type-add

# Search for 20_000 or 20000 patterns in test files
rg -n '20[_,]?000' scenarios/test_codegen/test/ --no-type-add

# Search for tooFarBlockRange references in test files
rg -n 'tooFarBlockRange' scenarios/test_codegen/test/ --no-type-add

Repository: enviodev/hyperindex

Length of output: 1807


🏁 Script executed:

#!/bin/bash
# Find .res test files in scenarios directory
fd . 'scenarios/test_codegen/test/' -e res | head -20

# Search for the gap pattern mentioned
rg 'Gap.*25099.*4999' scenarios/test_codegen/test/

# Search for 20000 or 20_000 patterns
rg '20[_,]?000' scenarios/test_codegen/test/

# Search for tooFarBlockRange references
rg 'tooFarBlockRange' scenarios/test_codegen/test/

Repository: enviodev/hyperindex

Length of output: 3329


🏁 Script executed:

#!/bin/bash
# Read E2E_test.res around the gap comment to see the actual assertion
rg -n -B10 -A15 'Gap = 25099 - 4999 = 20100' scenarios/test_codegen/test/E2E_test.res

# Also check FetchState_test.res to see if it will auto-adapt
rg -n -B5 -A5 'tooFarBlockRange \+' scenarios/test_codegen/test/lib_tests/FetchState_test.res | head -40

Repository: enviodev/hyperindex

Length of output: 2835


🏁 Script executed:

#!/bin/bash
# Get more context after the gap comment to see what the test asserts
rg -n -A50 'Gap = 25099 - 4999 = 20100' scenarios/test_codegen/test/E2E_test.res | head -80

Repository: enviodev/hyperindex

Length of output: 2368


Update E2E test expectations for new partition threshold.

The E2E test (E2E_test.res, line 1323) expects DC1 and DC2 to occupy separate partitions based on a gap of 20,100 blocks exceeding the old threshold of 20,000. With the new threshold of 50,000, this gap no longer exceeds the threshold, changing the partition strategy to merge. The assertion at line 1357 expects partitions [("2", 5000), ("3", 25100), ("0", 25101)] and will fail because the contracts should now be merged into a single partition instead of remaining separate.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/envio/src/FetchState.res` at line 203, The tooFarBlockRange
threshold in FetchState.res has been increased from 20,000 to 50,000 blocks.
This changes the partition strategy for the E2E test scenario: the 20,100 block
gap between DC1 and DC2 no longer exceeds the new threshold, so these contracts
should now merge into a single partition instead of remaining separate. Update
the test assertion in E2E_test.res (currently expecting partitions [("2", 5000),
("3", 25100), ("0", 25101)]) to reflect the new merged partition outcome that
results from this increased threshold.

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.

2 participants