code: Request value doesn't filter peers with `history_min_height` <= `height`

[ancazamfir]

• The syncing node does not look at the peer's status history_min_height ending up sending request to a peer that has pruned the height
• The peer that receives the request for a height it doesn't have will reply with empty response

2025-06-04T00:17:40.192164Z DEBUG node{moniker=actor-app-proposal-0}:sync{height.tip=25 height.sync=26}: Received request for value request.height=1 peer=12D3KooWS5U6trET7DpsEWvQGMQjiJ9p8VQpocxer4L3SMoKEnba2025-06-04T00:17:40.192235Z DEBUG node{moniker=actor-app-proposal-0}:host{height=26 round=0}: Received request for block height=12025-06-04T00:17:40.192480Z  WARN node{moniker=actor-app-proposal-0}:host{height=26 round=0}: No block for this height, available blocks: 15..=25 height=1
2025-06-04T00:17:40.192564Z ERROR node{moniker=actor-app-proposal-0}:sync{height.tip=25 height.sync=26}: Received empty value response from host height=1
2025-06-04T00:17:40.192629Z DEBUG node{moniker=actor-app-proposal-0}:network: Replied to Sync request request_id=1

• The syncing node receives the response:

2025-06-04T00:29:44.785978Z ERROR node{moniker=actor-app-proposal-2}:network: Failed to decode sync response: MissingField { type_url: "p2p.ValueResponse", field: "certificate" } peer=12D3KooWCsmmFZjWsYs6sTkTmfcAWSzinsktCfR4UCHdxkHk6Xsg

The issue here is that the syncing node is sending the request to a peer known to not have the desired height. The other logs look ok and can still happen when issue is fixed, if pruning occurs between status messages.

[ancazamfir]

• The syncing node receives the response:

2025-06-04T00:29:44.785978Z ERROR node{moniker=actor-app-proposal-2}:network: Failed to decode sync response: MissingField { type_url: "p2p.ValueResponse", field: "certificate" } peer=12D3KooWCsmmFZjWsYs6sTkTmfcAWSzinsktCfR4UCHdxkHk6Xsg

Looking at this again:

• We return error if response is empty
• The request stays pending and no other requests can be made

2025-06-04T01:49:37.509423Z  WARN node{moniker=actor-app-proposal-2}:sync{height.tip=0 height.sync=1}: SYNC REQUIRED: Falling behind height.tip=0 height.sync=1 height.peer=21
2025-06-04T01:49:37.509428Z  WARN node{moniker=actor-app-proposal-2}:sync{height.tip=0 height.sync=1}: Already have a pending value request for this height height.sync=1

• The request does eventually time out

2025-06-04T01:49:43.807846Z  WARN node{moniker=actor-app-proposal-2}:sync{height.tip=0 height.sync=1}: Timeout elapsed timeout=Request(OutboundRequestId("1"))
2025-06-04T01:49:43.807862Z  WARN node{moniker=actor-app-proposal-2}:sync{height.tip=0 height.sync=1}: Value request timed out peer_id=12D3KooWBED4VUk8ZzsULZ83NUpQnhcE96Dx32wznsnG4joteFTy height=1

A better handling would be to pass the empty response to subscribers, sync actor can immediately remove the pending request since we got a response (empty but still a response). The next request can then be made immediately (similar to what we do for invalid certificate).

[romac]

I believe the second issue might be a bug in the proto definition and Codec for SyncResponse in the actor-app-proposal app. In the existing Starknet and test apps, we handle things properly as far as I can tell.

[ancazamfir]

I believe the second issue might be a bug in the proto definition and Codec for SyncResponse in the actor-app-proposal app. In the existing Starknet and test apps, we handle things properly as far as I can tell.

I was able to repro this with starknet app by setting a small pruning window and trying to sync (without the fix from first bullet). In general if a peer sends a response that cannot be deserialized (buggy or byzantine or block has been pruned between request and response) sync is blocked until the request times out.