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.

[github-actions]

Findings

• High – validator/manager.cpp:496: create_block returns td::Result<td::Ref<BlockData>>, not an awaitable task. co_await create_block(block_id, std::move(data)); will not compile with the current signature. You probably meant to call it synchronously and handle the Result (and errors) before proceeding.
• Medium – validator/manager.cpp:532-543: Collator notifications were moved ahead of the validator/nonfinal gate and the duplicate-broadcast check. Collator nodes now get new_shard_block_accepted even on non-validator nodes and for duplicate shard block descriptions, causing redundant work and potentially unexpected collator activity on observer nodes. These notifications previously ran only after the duplicate check and only for validators.

The PR adds nonfinal LS pending-blocks queries and DB event FIFO publishing; once the above issues are addressed, consider rerunning the build to ensure the coroutine changes compile.

[github-actions]

• validator/manager.cpp:479-502 – new_block_candidate_broadcast now awaits wait_block_state before updating nonfinal_info_ or emitting the blockCandidateReceived event. If the state/proof fetch returns notready/timeout (common for fresh nonfinal shards), the coroutine returns early and the candidate is never recorded or reported to the new pending API. That makes nonfinal.getPendingShardBlocks silently miss candidates whenever state acquisition lags. Consider updating the pending/candidate bookkeeping (and event) before the blocking state download, or at least handling failures separately so candidates are still visible.
• validator/manager.cpp:479-502 – Enabling nonfinal_ls_queries_enabled now drives wait_block_state and set_block_data for every incoming candidate broadcast, fetching proofs/states from the network and writing block data to disk even for untrusted/outdated candidates. Previously this work was deferred and bounded in the in‑memory candidates buffer. A malicious peer can flood candidate broadcasts and force expensive state downloads/DB writes. It would be safer to gate this (e.g., validate group first, rate‑limit, or keep the heavy work lazy/on‑demand).

[github-actions]

Findings

• validator/manager.cpp:482-516 now persists every block candidate broadcast to the main block DB and kicks off a full wait_block_state/store cycle whenever nonfinal_ls_queries_enabled is on. The data and shard state download happen before any validation and without any TTL/limit. With CandidatesBuffer removed (validator/impl/candidates-buffer.cpp deleted), untrusted candidate broadcasts can now trigger unbounded disk writes and state fetches, letting a peer fill storage or saturate the node simply by spamming candidates once this flag is enabled.

If you want, I can propose a bounded/ephemeral path for nonfinal candidates to keep the new LS feature without opening a persistence/DoS hole.