fix(ec): stop prior Kad search when EC client starts any new search - #36
Merged
got3nks merged 1 commit intoJun 9, 2026
Conversation
When an EC client (amuleweb / amulegui) starts a new search, the daemon's `Get_EC_Response_Search` invokes `searchlist->RemoveResults(0xffffffff)` which calls `CSearchManager::StopSearch(0xffffffff, /*delayDelete=*/true)`. The delay-delete flag deliberately keeps the `CSearch` object in `m_searches` so late-arriving Kad reply packets can still be processed. Post-3008ada0f, EC clients pass `0xffffffff` for any search type. When an EC ed2k search starts immediately after a Kad search, the still-alive prior Kad search continues firing `KademliaSearchKeyword(0xffffffff, ...)` for late UDP replies, and those results land in `m_results[0xffffffff]` -- the same bucket the new ed2k search is filling via `m_currentSearch=0xffffffff` + `ProcessSearchAnswer`. The user sees Kad-flavored hits mixed in with their ed2k results. The pre-existing hard-stop inside the Kad branch of `CSearchList::StartNewSearch` already terminates the prior Kad search when both old and new searches are Kad. Hoisting that hard- stop out of the `if (type == KadSearch)` block makes it fire for any EC-driven new search regardless of type, terminating the stale Kad search before it can contaminate the new bucket. Native-GUI searches are unaffected: `CSearchDlg::StartNewSearch` allocates bottom-half IDs (`m_nSearchID & 0x7fffffff`), so the `*searchID == 0xffffffff` gate skips them. They keep their per- tab `m_results[id]` isolation.
got3nks
marked this pull request as draft
June 9, 2026 15:56
got3nks
marked this pull request as ready for review
June 9, 2026 16:09
3 tasks
got3nks
added a commit
that referenced
this pull request
Jun 9, 2026
#37) PR #36 hard-stops the previous Kad search when an EC client starts any new search, blocking late KademliaSearchKeyword(0xffffffff, ...) callbacks from contaminating the new search's m_results[0xffffffff] bucket. The reverse direction was unfixed: late ed2k server replies (TCP Local in ProcessSearchAnswer, UDP Global in ProcessUDPSearchAnswer) keep arriving for seconds after the request was sent and continue calling AddToList with searchID = m_currentSearch. With the EC sentinel `0xffffffff` pinned across all EC searches, those late results land in the new (Kad) search's bucket -- ed2k contamination of a Kad result list, symmetric to the Kad contamination of an ed2k list that PR #36 fixed. Drop late ed2k replies when the active search type is no longer ed2k. Same shape as PR #36's StopSearch hoist: cheap one-line gate that closes the bucket on the protocol level. Native-GUI parallel searches: a Kad tab updates m_searchType to KadSearch, so this gate also drops late ed2k packets that would otherwise misroute to the Kad tab's m_results[m_currentSearch]. Pre-existing GUI misrouting bug that wasn't visible because cross- protocol hits in a Kad tab look like generic Kad noise; the right fix there is per-search-object tracking on the ed2k side (mirroring CSearch), out of scope for this hotfix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When an EC client (amuleweb / amulegui / amulecmd) starts a new search via
EC_OP_SEARCH_START, the daemon's previous Kad search wasn't being terminated unless the new search was also Kad — so late-arriving Kad reply packets continued feeding the sharedm_results[0xffffffff]bucket while the new search was filling it. Switching from Kad → ed2k (Local or Global) via the web UI ends up showing Kad results mixed in with the ed2k server replies.Root cause
EC clients pass
0xfffffffftoCSearchList::StartNewSearchregardless of search type, per the partition agreed in3008ada0f(native GUI uses bottom-half IDs, Kad-allocated uses top half,0xffffffffreserved as the EC sentinel).The daemon's
Get_EC_Response_Searchalready callsRemoveResults(0xffffffff)to clear the bucket, but that path invokesCSearchManager::StopSearch(0xffffffff, /*delayDelete=*/true)which only marks the prior Kad search for cleanup viaPrepareToStop()so it can still drain in-flight packets. Those drained packets callKademliaSearchKeyword(0xffffffff, ...)andAddToListputs them right back into the bucket the new search has just started using.Inside
CSearchList::StartNewSearchitself there's already a hard-delete (StopSearch(0xffffffff, false)) — but it's gated underif (type == KadSearch), so it only runs when the new search is also Kad. The cross-type case (Kad → ed2k) leaves the soft-stopped Kad search alive.Fix
Hoist the hard-delete out of the
if (type == KadSearch)block so it fires for any EC-driven new search, before either Kad'sPrepareFindKeywordsor ed2k's server packet starts feedingm_results[0xffffffff].Why monolithic / native GUI is unaffected
CSearchDlg::StartNewSearchallocates bottom-half IDs (m_nSearchID & 0x7fffffff), so the new gateif (*searchID == 0xffffffff)is false for native-GUI calls. Their per-tabm_results[id]isolation is unchanged. Multiple parallel Kad searches + one ed2k search continue to work because each tab's Kad-allocated top-half ID and each ed2k search's bottom-half ID are distinct buckets, fed by codepaths that own those IDs.Test plan
Discovered while triaging #31. PR #33 fixed the amuleweb-side rendering bug; this fixes the orthogonal daemon-side cross-type contamination.