test: fix blocked peers test suite (update propagation through gateway)

[sanity]

Parent Issue

Part of #2021 - fixing ignored integration tests

Problem

All three blocked peers test variants are currently ignored despite having a well-designed parameterized test framework.

Affected tests:

• apps/freenet-ping/app/tests/run_app_blocked_peers.rs::test_ping_blocked_peers
• apps/freenet-ping/app/tests/run_app_blocked_peers.rs::test_ping_blocked_peers_simple
• apps/freenet-ping/app/tests/run_app_blocked_peers.rs::test_ping_blocked_peers_solution

Current status:

• First two: #[ignore] (no reason given)
• Third: #[ignore = "fix me"]

Ignored by: @sanity in commit feccbde (June 3, 2025)

Test Description

These tests verify a critical network scenario: contract state updates propagating through gateway nodes when direct peer-to-peer connections are blocked.

Test topology:

Gateway (no blocks)
  ├── Node1 (blocks Node2)
  └── Node2 (blocks Node1)

Test flow:

1. Set up 3 nodes with mutual blocking between Node1 and Node2
2. Deploy ping contract on gateway
3. All nodes subscribe to the contract
4. Each node sends updates with unique tags
5. Verify all nodes receive all updates (via gateway routing)
6. Confirm state convergence across all nodes

This validates that the DHT routing and subscription propagation work correctly when direct connections are unavailable.

Test Framework Design

The file implements a sophisticated parameterized test framework (BlockedPeersConfig) with configurable:

• Timeouts and delays
• Update rounds and strategies
• Subscription approaches (immediate vs deferred)
• Check intervals and verification methods
• Refresh and final update behavior

Three test variants exist:

• baseline: Standard configuration with multiple update rounds
• simple: Minimalist approach with single update round
• solution: Reference implementation with regular checks and refresh updates

Expected Behavior

1. Nodes start successfully with blocked peer lists configured
2. Subscriptions are established on all nodes
3. Updates from any node propagate to all other nodes via gateway
4. All nodes converge to identical final state
5. Test assertions pass for cross-node update visibility

Actual Behavior

Unknown - tests are ignored. Likely failures include:

• Updates not propagating through gateway
• Subscription not working with blocked peers
• State divergence between nodes
• Timeout issues in update propagation

Investigation Tasks

• Run test_ping_blocked_peers_simple first (simplest variant)
• Run with RUST_LOG=debug to trace update propagation
• Verify blocked peer configuration is correctly applied
• Check if subscriptions are established on all nodes
• Trace update messages through gateway routing
• Identify where propagation fails (if it does)
• Run all three variants to understand which strategies work
• Compare against non-blocked multi-node tests to isolate blocking-specific issues

Technical Considerations

Subscription Propagation

The core challenge is ensuring subscription updates propagate through intermediary nodes (gateway) when direct connections don't exist.

DHT Routing

Updates must be correctly routed through the DHT even when the shortest path (direct connection) is blocked.

State Convergence

All nodes must eventually reach the same state despite asymmetric connectivity.

Related Code

• Test file: apps/freenet-ping/app/tests/run_app_blocked_peers.rs
• Core implementation: run_blocked_peers_test() function
• Related: DHT routing logic, subscription propagation code

Success Criteria

• Identify root cause of test failures
• Fix underlying bugs in routing/subscription propagation (if production bug)
• OR fix test logic (if test bug)
• All three test variants pass locally
• Tests pass in CI
• Remove all #[ignore] annotations
• Document expected behavior for blocked peer scenarios

Impact

E-hard - This is a complex distributed systems scenario involving:

• Multi-node coordination
• Indirect routing through gateway
• Subscription propagation across topology
• State convergence verification

The sophisticated test framework suggests significant prior investment; getting these tests working will provide valuable coverage for production edge cases.

[AI-assisted debugging and comment]

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (95% confidence)
• P-high (85% confidence)
• E-hard (80% confidence)
• A-networking (95% confidence)
• A-developer-xp (80% confidence)
• S-needs-reproduction (90% confidence)

Reasoning: The issue describes ignored integration tests that exercise subscription propagation and DHT routing when direct peer connections are blocked. This indicates a broken behavior either in the networking/subscription propagation code or in the tests themselves, so T-bug is appropriate. The problem impacts a critical distributed-network scenario and test coverage, meriting high priority. The task is complex (multi-node routing, gateway behavior, timing), so E-hard fits. Relevant areas are networking (routing/subscriptions) and developer experience (tests/CI). The current state requires running and reproducing the tests, so S-needs-reproduction is included.

Previous labels: E-hard, A-networking, S-needs-reproduction

If these labels are incorrect, please update them. This helps improve the auto-labeling system.