[HagarMeir]

Written by Claude (Anthropic's AI assistant) on behalf of Hagar Meir.

Fixes #712.

The controller informs the view changer of a new view after a sync, from its run loop. InformNewView sent on a channel with a buffer of one. So if the view changer hadn't yet processed the previous view, the controller's run loop blocked until it did.

Changes

• InformNewView never blocks. If a view is already pending, it keeps only the higher of the two, so the view changer still moves to the latest view.
• TestInformNewViewDoesNotBlock informs a view changer that isn't running yet of three views. It checks that no call blocks, and that the view changer ends up in the latest view. On main the second call blocks.
• TestInformViewChanger used to call InformNewView twice, relying on the second call blocking to know the first was processed. It now waits for the view changer to restart the request timers, which it does once it processes the view.

🤖 Generated with Claude Code

[pfi79]

1. Is the “max pending view” write race-free, or is the single-threaded invariant documented?
   Please point to the field/update in InformNewView and confirm it is mutex/atomic-protected, or that a comment explicitly states it is only called from the controller run loop.

2. Does TestInformViewChanger avoid time.Sleep-based synchronization?
   Please point to the channel/Eventually/signal the test uses to wait for timer restart — not a sleep.

3. Is there a comment explaining “don’t block, keep the max”?
   Please point to the comment near the pending-view logic that documents why we keep only the highest view instead of blocking.

[HagarMeir]

Thanks for the review!

1. There's no shared field: the pending view is held only in informChan (buffer of one), and view is local to the call, so the channel operations are the only synchronization needed and concurrent calls are safe. The only caller today is Controller.sync on the controller's run loop, but the code doesn't rely on it. I've added this to the comment.
2. Yes, no sleeps. Both tests wait on the informed channel, which the RestartTimers mock signals once the view changer processes the view (time.After is only used as a failure timeout).
3. Expanded the comment on InformNewView to explain why it must not block and why keeping only the highest view loses nothing (1799c74).

(Written by Claude on behalf of Hagar Meir.)