`KBucketsTable.applied_pending` is confusing
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 5.6k
- Forks
- 1.3k
- Avg merge
- 8h 47m
- Merged PRs (30d)
- 19
Description
I was looking into https://github.com/libp2p/rust-libp2p/issues/5626 and noticed that all iterators require exclusive (mutable) access to the whole KBucketsTable, moreover, its buckets are being modified during iteration over k-buckets, which is extremely confusing and feels like a completely arbitrary place to do this:
https://github.com/libp2p/rust-libp2p/blob/417968e07cfb79163a541ee2e5871a9bb6fe9534/protocols/kad/src/kbucket.rs#L463-L501
Specifically this part:
https://github.com/libp2p/rust-libp2p/blob/417968e07cfb79163a541ee2e5871a9bb6fe9534/protocols/kad/src/kbucket.rs#L482-L485
I did a quick look around, but wasn't able to easily fix this. Someone with better knowledge of the codebase should look into it. It is very hard to maintain the project when code so convoluted.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in protocols/kad/src/kbucket.rs, especially the KBucketsTable iterator implementation around lines 463-501 and the applied_pending logic at lines 482-485. Read issue #5626 for context, then trace the iterator callers and existing Kademlia tests. Done means the confusing mutation during iteration and broad mutable access are addressed with behavior-preserving test coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100