Improve accessing nonfinal blocks through LS

[SpyCheese]

No description provided.

[github-actions]

Changes look aimed at serving nonfinal blocks via liteserver and publishing DB events. I spotted a couple of issues in the new code.

• validator/manager.cpp:550 – Ref<BlockData> is used without the td:: qualifier and there’s no using td::Ref in this file. This won’t compile (Ref is undefined here). Use td::Ref<BlockData> (or add the using) before the coroutine can build.
• validator/manager.cpp:245-249 (and similarly the coroutine at 548-553): the new coroutine paths are ask(...).detach() and then co_await operations that return td::Result values, but errors are never handled. Any timeout/error in wait_block_state_short, create_block, etc., will abort the coroutine, so process_accepted_nonfinal_block/DB events and nonfinal tracking silently never run even though the block was validated. Consider capturing the result, logging failures, and still deciding whether to emit the nonfinal/DB events.

Let me know if you want me to draft a fix for these.

[github-actions]

• validator/manager.cpp:239-249, 608-622, 3807-3824 – process_accepted_nonfinal_block now fires from both validated_block_broadcast and add_shard_block_description. For a block that goes through normal validation plus the shard-block-description path we’ll publish db_event_blockSigned twice (no dedup guard in the event emitter even though the map ignores duplicates). That makes the new FIFO stream double-count signed blocks. Consider emitting the event only once per block or short-circuiting if the map already contains that seqno.

• validator/manager.cpp:536-569 – On every candidate broadcast, when non-final LS queries are enabled we store the candidate into the DB and wait for full state (set_block_data + wait_block_state) before even checking whether the catchain group is valid for the current shard client state. When the shard client is not ready or the group is stale, is_valid_nonfinal_group will discard the result but we still persist untrusted candidate data and kick off expensive state downloads. Should we first verify the group is valid and shard_client_state_ is available before writing to the DB / downloading state?

[github-actions]

@codex review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.

[kulih-kyber]

Кен

[github-actions]

@codex review

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.