IPC client has no timeout — hung PoW node blocks finality gadget indefinitely

[MastaP]

Summary

`pow/ipc_client.go:27-37` — The `http.Client` created in `NewIPCClient` has no `Timeout` set. The `DialContext` function in the transport uses `net.Dial` instead of `net.DialContext`, ignoring the provided context (and any deadline on it).

If the PoW node socket exists but the process hangs, the HTTP request blocks indefinitely, halting the entire BFT partition.

Severity

High — liveness issue; a single unresponsive PoW node can halt the finality gadget.

Suggested Fix

client := &http.Client{
    Timeout: 10 * time.Second, // adjust as appropriate
    Transport: &http.Transport{
        DialContext: func(ctx context.Context, _, _ string) (net.Conn, error) {
            d := net.Dialer{}
            return d.DialContext(ctx, "unix", socketPath)
        },
    },
}

Related

• `io.ReadAll(resp.Body)` at line 89 has no size limit — a compromised PoW node can return an arbitrarily large response causing OOM.
• No validation of block header data from the PoW node (hash format, length, consistency with queried parameters) at lines 150-156.
• JSON-RPC request ID is hardcoded to `1` and response ID is never validated.

[b3y0urs3lf]

Additional Findings: T1 Timer Not Rescheduled After IPC Failure → Cluster Permanently Stuck

During integration testing of FGP with unicity-node (PoW), we discovered a secondary bug
triggered by IPC failures that makes the impact of #6 worse than originally described.

The Problem

When LeaderPropose() fails due to an IPC error (connection reset, timeout, etc.), the handler
in partition/round.go:61-65 returns without rescheduling the T1 timer:

stateSummary, err := n.transactionSystem.LeaderPropose(ctx, n.currentRoundNumber())
if err != nil {
    n.log.WarnContext(ctx, "Leader failed to apply block state transition", logger.Error(err))
    n.transactionSystem.Revert()
    return  // ← BUG: T1 timer was already stopped (line 43-46), never restarted
}

The T1 timer is stopped at the top of handleT1TimeoutEvent() (lines 43-46) and only restarted
when startNewRound() is called after receiving a UC from BFT. But since no proposal was sent,
BFT never issues a UC → no new round → no new timer → cluster permanently stuck.

Reproduction

1. Start unicity-node --testnet + startmining
2. Start 3 FGP nodes with --t1-timeout 60000 (60s) pointing to the same PoW socket
3. Wait 1-4 rounds — leader hits connection reset by peer on node.sock
4. All 3 FGP nodes freeze permanently — no further T1 timeouts fire

IPC Socket Contention (Root Trigger)

The IPC failure is caused by socket contention on the PoW node side:

• All 3 FGP nodes have synchronized T1 timers (started at the same time) — they all
  fire within 35ms of each other
• The leader makes 4-6 sequential RPC calls per round, each opening a new connection
• The PoW node's listen() backlog is 20 (rpc_server.cpp:209), but under 90% CPU load
  from mining, the accept() loop is starved → kernel RSTs queued connections
• This reproduces consistently on both unicity-pow (backlog=5) and unicity-node (backlog=20)

Separate bug reports will be filed for the PoW node IPC serve.