Fix chain_state tracking for empty blocks (v1.4.4)

[papadritta]

Problem

In v1.4.4, commit 3f9ee6c introduced an optimization to skip committing empty blocks. However, this caused chain_state to stop updating during sequences of empty blocks, making the indexer appear frozen even though it continued processing blocks internally.

Impact:

• Operators cannot monitor indexer progress through empty block sequences
• Impossible to distinguish between a working indexer and a crashed one
• Health checks fail incorrectly
• API endpoint shows stale height during periods without MASP transactions

Solution

This fix maintains the performance optimization while ensuring chain_state updates for all blocks by:

• Adding fast-path commit for empty blocks (skips expensive MASP processing)
• Removing the skip logic that prevented chain_state updates
• Preserving API visibility of indexer progress

Fixes progress tracking regression introduced in v1.4.4.

Testing

Checked on Mainnet: namada.5f5de2dd1b88cba30586420

• Masp-indexer endpoint: https://masp-indexer.papadritta.com/api/v1/height
• Verified chain_state updates continuously through empty blocks

Checked on Testnet: housefire-alpaca.cc0d3e0c033be

• Masp-indexer endpoint: https://housefire.masp-indexer.papadritta.com/api/v1/height
• Confirmed indexer maintains progress visibility

Both deployments show correct behavior with the fix applied.

[sug0]

Operators cannot monitor indexer progress through empty block sequences

this is not true. INFO logs are emitted by the chain service, telling you empty blocks are being skipped. this should be enough for you to monitor the health of the service.

This fix maintains the performance optimization

this PR doesn't optimize anything. it just reverts the changes introduced by commit 3f9ee6c in a contrived way. the whole point of those changes were to avoid unnecessarily querying postgres. another advantage of only advancing to heights that contain masp txs is that you don't need to waste time syncing empty blocks. the height pointed to by /api/v1/height is always the latest height that contains a masp tx.

[sug0]

I'll be closing this PR, since IMO these changes will result in a performance regression with no added benefit (outside of the convenience of monitoring the health of the service from an HTTP endpoint vs. parsing logs through grafana or smth)

[papadritta]

@sug0 Got it, thanks for explaining the reasoning behind this. Makes sense now.
Appreciate you taking the time to review.