feat(blockchain): log when block building finishes

[MegaRedHand]

What

Adds an info-level "Finished building block" log in propose_block, emitted right after the block-building timing guard is dropped.

Why

The timing guard is dropped deliberately before the publish-alignment wait so that wait does not count toward the block_building metric. Logging at that exact point makes the build's completion visible and marks the boundary between build time and the alignment wait in logs, complementing the existing "We are the proposer for this slot" (start) and "Published block" (publish) lines.

Follows the established %slot, %validator_id field convention used throughout the function.

[github-actions]

🤖 Codex Code Review

No findings.

The only change at crates/blockchain/src/lib.rs:621 adds an info! on the proposer path after drop(timing) and before the slot-boundary wait/publication path. That means it does not affect block-building metrics, fork choice, attestation validation, justification/finalization, state transition, XMSS handling, or SSZ encoding/decoding.

Minor note: this adds one extra info log per locally proposed block, but I do not see a correctness, security, or performance concern from it. I did not run tests, since the diff is logging-only.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

[github-actions]

🤖 Kimi Code Review

The change adds an observability log marking the completion of block building. The implementation is correct and appropriately placed.

Minor considerations:

1. Privacy/Security (line 621): Logging validator_id (validator index) reveals which validators are active on this node. While this is standard practice in consensus clients and the data is public on-chain, ensure operators are aware this appears in logs at INFO level. Consider if this could aid targeted DoS attacks against specific node operators.

2. Trait bounds: Verify that slot and validator_id implement Display (required by the % formatter). If these are custom types, ensure the Display implementation doesn't expose sensitive internal state.

3. Timing correctness: The placement after drop(timing) (line 618) is correct—logging I/O won't skew the block-building performance metric.

Verdict: Acceptable. No blocking issues.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[greptile-apps]

Greptile Summary

This PR adds a block-build completion log in propose_block. The main change is:

• Logs Finished building block after the build timing guard is dropped.
• Keeps the log before the publish-alignment wait.
• Uses the existing slot and validator_id tracing fields.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
crates/blockchain/src/lib.rs	Adds one info log after drop(timing) in propose_block to mark the end of block building.

_{Reviews (1): Last reviewed commit: "feat(blockchain): log when block buildin..." | Re-trigger Greptile}

[github-actions]

🤖 Claude Code Review

Review of PR 474 — feat(blockchain): log when block building finishes

Overview: This is a minimal, single-line addition that inserts an info! log after the block-building timing guard is dropped in propose_block. The intent is to mark the precise boundary between build time and the alignment wait, complementing the existing "We are the proposer for this slot" (line 482) and "Published block" (line 658) log lines.

---

No findings. The change is correct and clean:

• The new log is placed at exactly the right point — after drop(timing) and before the alignment sleep — so it truthfully marks "build done" without inflating the block_building metric.
• %slot and %validator_id are both in scope and valid at this point.
• Field ordering (%slot → %validator_id) follows the temporal → identity convention from CLAUDE.md and matches the bookend log lines verbatim.
• The shorthand %field syntax is used correctly per project convention.
• No functions were modified, no callers affected, and no behavior was removed.

The PR does exactly what it says, in the right place, with the right format.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt