Repository navigation
Closed
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/xsTrivial: expected under 30 minutes of workTrivial: expected under 30 minutes of workkind/choreRoutine maintenance, housekeeping, dependency hygieneRoutine maintenance, housekeeping, dependency hygienepriority/lowNice to have; do when convenientNice to have; do when convenientsource/pr-diff-reviewFiled by the pr-diff-review jobFiled by the pr-diff-review jobstatus:donetask/pr-shepherdQueue packet kind: shepherd an open PR or PR set to mergeQueue packet kind: shepherd an open PR or PR set to merge
Description
Finding
Open PR #3678 is a superseded duplicate of merged PR #3688. Both PRs implement the same fix for issue #3013 — memoize the subject_kind lookup in search_terms so it runs at most once per subject — from the same queue task (task 5518). Issue #3013 is CLOSED, the merged implementation is on current main, and PR #3678 is now conflicting and unmergeable. It should be closed as superseded, not merged.
Evidence
- PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678 (id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678): OPEN, verified twice via REST this run —
mergeable=false,mergeable_state=dirty; head3453e65cb1on branchqueue/5518-3013-search-memoize; created 2026-11-01T12:34:40Z, last updated 2026-11-01T16:18:41Z. Body: "Fixes id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013. Queue task 5518". - PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688 (id(search): memoize subject_kind resolution in search_terms (#3013) #3688): MERGED 2026-11-02T15:57:09Z, merge commit
54cbdaf9ce520f65a4c7dd2d2b3a2c108b6962cc, verified ancestor of current mainafdad961081c8a0053b014f91ec36e470e96f4e4(compare API: status ahead, behind_by 0). Body: "Fixes id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 (queue task 5518)". - Same two files, same change: both diff against the identical base blob
7bec033cbofpkgs/id/src/search.rsand both add a per-call memo insearch_terms(PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678: aRefCell<HashMap>kind_cache; PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688: a plainHashMapkind_memo), and both add a test with the identical nametest_search_terms_resolves_subject_kind_at_most_once_per_subjectinpkgs/id/tests/search.rs— merging PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678 would conflict and would duplicate the test name. - Current main carries the merged version exactly: the blob sha of
pkgs/id/src/search.rson main is53be0f5b3, which is PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688's post-image blob (PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678's post-image is977dd2f5a, not on main). - Issue id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 is CLOSED (verified via REST this run).
- Dedupe: issue searches for "3678" and for open pr-shepherd/superseded items this run found no existing issue tracking PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678's disposition; the only hit was issue id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 itself (CLOSED).
Why it matters
No live defect — the fix is already on main. The risk is a future accidental merge attempt or rebase of PR #3678 duplicating the memoization (and colliding on the identical test name), plus open-list noise: the open PR reads as an unlanded fix for a closed issue.
Acceptance criteria
- PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678 is closed (not merged) with a comment citing PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688 and closed issue id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 as the landing of the same queue task 5518 work.
- Before closing, PR id(search): memoize subject_kind resolution in search_terms — at most once per subject (#3013) #3678's test variant is dispositioned: its two scenarios (duplicate kind terms in one call; a distinct kind term adding no new lookups within the same call) are confirmed covered by PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688's merged test (3 kind terms incl. a duplicate, exactly 3 lookups, plus the single-term result check), or any genuinely uncovered scenario is ported in a separate small PR and the closing comment records the decision.
- After closing, exactly one
subject_kindmemoization exists inpkgs/id/src/search.rson main and issue id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 remains closed.
Metadata
Metadata
Assignees
Labels
app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)effort/xsTrivial: expected under 30 minutes of workTrivial: expected under 30 minutes of workkind/choreRoutine maintenance, housekeeping, dependency hygieneRoutine maintenance, housekeeping, dependency hygienepriority/lowNice to have; do when convenientNice to have; do when convenientsource/pr-diff-reviewFiled by the pr-diff-review jobFiled by the pr-diff-review jobstatus:donetask/pr-shepherdQueue packet kind: shepherd an open PR or PR set to mergeQueue packet kind: shepherd an open PR or PR set to merge
Activity
developing-today commentedon Nov 6, 2026
CODE-2016
dezren39 commentedon Nov 6, 2026
🤖 Agent note · state: filed
dezren39 commentedon Nov 7, 2026
Picked up by repo-worker-code-w (Lane W, fallback mode — queue backend down; fallback marker protocol run manually via gh per doc/fleet/queue-fallback-mode.md).
🤖 Agent note · picked up
dezren39 commentedon Nov 7, 2026
🤖 Agent note · picked up
repo-worker-code-a(issue Close PR #3678 as superseded by merged PR #3688 — both implement the #3013 subject_kind memoization from queue task 5518 #6608 is the task in fallback mode)queue/queueditems in scan order)54cbdaf9ce) · issue id(search): search_terms re-calls the subject_kind lookup once per SubjectKind term per subject — its doc promises at most once per subject, so a two-kind-term search does twice the store reads #3013 (closed)dezren39 commentedon Nov 7, 2026
Stand-down note from queue worker lane code-a: my pickup note above raced lane code-w's fallback claim — the claim fold shows
repo-worker-code-wholds the live claim on issue #6608 (claimed 2026-11-07T03:03:10Z), and my own claim attempt was refused (live_claim). I have done no work on PR #3678 beyond reading the two PR diffs locally, and I am standing down; the label state (status/in-progress added, status/needs-triage removed) matches the standard claim transition for the actual holder. — repo-worker-code-adezren39 commentedon Nov 7, 2026
Released by repo-worker-code-w (Lane W, fallback mode) — outcome: done. PR #3678 is CLOSED (not merged); salvage note posted on canonical PR #3688.
🤖 Agent note · done
origin/mainpkgs/id/src/search.rscarries exactly one memoization (kind_memo, PR id(search): memoize subject_kind resolution in search_terms (#3013) #3688's version —kind_cacheabsent)