fix: use calculated end_block for native_transfer_block_fetch

[outerlook]

Summary

Pass the calculated end_block from get_start_end_block() instead of network_details.end_block to native_transfer_block_fetch().

Problem

When end_block is not set in the manifest, network_details.end_block is None, causing native_transfer_block_fetch to loop forever waiting for new blocks. This blocks try_join_all in start_indexing, preventing:

• Historical indexing from completing
• Live indexing from ever starting
• All contract events from being indexed

Fix

Use the calculated end_block (which defaults to latest_block when not specified in manifest) instead of the raw manifest value. This aligns native transfer behavior with contract events.

Fixes #367

[vercel]

@outerlook is attempting to deploy a commit to the joshaavecom's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
rindexer-documentation	Ready	Preview, Comment	Feb 3, 2026 4:18pm

[jaggad]

@outerlook

When end_block is not set in the manifest, network_details.end_block is None, causing native_transfer_block_fetch to loop forever waiting for new blocks. This blocks try_join_all in start_indexing, preventing:

Can you please confirm by sharing logs or that it was validated in testing that the following conditions hold true with the current changes:

When start block is defined:

1. start_block: N defined for all contracts and native transfer indexing (as such historical indexing will be needed here)
2. it completes historical indexing up to current head block
3. Then. Does it still continue indexing native transfers "live" in this setup? <--- this point to be confirmed

When start block is not defined:

1. No start block defined
2. Historical indexing process should skip or finish quickly
3. Live indexing does in fact index native transfers <--- this point to be confirmed

[joshstevens19]

@outerlook

When end_block is not set in the manifest, network_details.end_block is None, causing native_transfer_block_fetch to loop forever waiting for new blocks. This blocks try_join_all in start_indexing, preventing:

Can you please confirm by sharing logs or that it was validated in testing that the following conditions hold true with the current changes:

When start block is defined:

1. start_block: N defined for all contracts and native transfer indexing (as such historical indexing will be needed here)
2. it completes historical indexing up to current head block
3. Then. Does it still continue indexing native transfers "live" in this setup? <--- this point to be confirmed

When start block is not defined:

1. No start block defined
2. Historical indexing process should skip or finish quickly
3. Live indexing does in fact index native transfers <--- this point to be confirmed

@outerlook did you manage to do this?

[outerlook]

Hey Josh! I want to do this next week... There's something at work with a deadline nearby (as everyone I imagine 😆)