Tests for Connected Peers & Concurrency Limits – Pointers & Follow-Up

[seetadev]

@sukhman-sukh : awesome progress so far! 🙌

Fantastic job digging into the tests and improving robustness. Just wanted to capture our latest discussion around the test cases for connected peers, concurrency limits with trio.CapacityLimiter, and possible extensions around retry/backoff logic.

Here’s a recap of the test goals, strategies, and how we can move forward:

Test 1: Connected Peers Only

You're spot on: the old code used host.get_peerstore().peer_ids(), which included stale peers. Your change to host.get_connected_peers() is the correct behavior.

Goal: Ensure only actively connected peers are used in operations.

Suggested test:
Create a test that:

• Mocks a few peer connections
• Confirms that only those returned by get_connected_peers() are acted upon
• Ensures stale/disconnected peers are ignored

Test 2: trio.CapacityLimiter — Bounded Concurrency

You're right — there’s no timeout or failure expected here. The test isn’t about catching errors but verifying that concurrency is being limited as intended.

Suggested Strategy:

1. Mock or wrap the push function to:

   • Sleep briefly (e.g. 0.2s)
   • Log when each call starts and ends

2. Launch 30+ push operations

3. Track the number of concurrent calls using a shared counter or async-safe logger

4. Assert: No more than 10 concurrent calls are in flight at any time

This helps us ensure the queueing behavior under load is working as expected.

Optional: Timeout or Retry/Backoff Logic

You're right again: the current logic just queues requests — it doesn’t timeout or back off.

If we want retry or backoff in the future, we’d need to:

• Add retry/backoff logic (e.g. exponential with jitter)
• Add test cases to simulate transient failures or dropped connections

Not required right now, but definitely something we can track as a future enhancement.

Next Steps:

• Implement test for get_connected_peers() usage
• Write concurrency test verifying the limiter holds at 10 max
• Optionally open a separate thread/issue for retries & backoff enhancements

Thanks again for all the thoughtful work here. Let us know if you'd like help mocking any parts of the test or if you want to pair on verifying concurrency under test conditions.

[sukhman-sukh]

Thanks @seetadev for elaborating on testing issues and future goals. I will push both tests for now and create an issue for this, along with a pull request adding backoff and retries.