Conversation
d73962d to
c31485a
Compare
|
Rebased onto the latest No review comments on this PR. CI will verify the build and test gate. |
c31485a to
06d5642
Compare
🔐 Codex Security Review
|
|
Rebased onto the latest Still-needed assessment: No upstream commits in the 62-commit window address the same issue. This PR remains needed. Review requests: |
06d5642 to
bb892d7
Compare
|
Rebased onto current Still needed: Checked all 38 new upstream commits for overlap with this PR's topic. None of the upstream changes address the issue this PR fixes. The PR remains relevant. Verification:
|
bb892d7 to
cbaae64
Compare
Rebase and review — 2026-09-03Base commit: Accuracy review: The root filter in |
cbaae64 to
0239d22
Compare
Rebase and review update — Sep 3, 2026Rebased onto latest main ( Accuracy review: Main already includes Mergeable status: Confirmed MERGEABLE on GitHub after force-push. |
0239d22 to
43fc3aa
Compare
Rebase pass — Sep 5, 2025Rebased onto current upstream main ( Rebase resultConflict resolved in crates/buzz-cli/src/commands/messages.rs (test import list — upstream added format_events import, PR added build_thread_root_filter import; merged both). Still-needed assessmentChecked all 62 new main commits for overlap with this PR's topic. None obsoleted:
Verification
|
43fc3aa to
ec8e64c
Compare
Rebase pass — Sep 9, 2026Rebased onto current upstream main ( Rebase resultRebased cleanly onto current main. No conflicts. Still-needed assessmentChecked all 8 new main commits for overlap with this PR's topic. None obsoleted. None of the 8 new main commits apply --channel to the thread root filter. Verification
|
Extract build_thread_root_filter as a pure function so the exact filter shape (ids + #h + limit, no kinds) is directly testable. Add a regression test that asserts the channel constraint is present. Correct the comment: the reply filter is scoped to known reply kinds, not unrestricted; the root filter is the one with no kind restriction. Addresses themiguelamador's review feedback. Co-authored-by: Brad Groux <brad@digitalmeld.com> Signed-off-by: Brad Groux <brad@digitalmeld.com> Signed-off-by: Brad Groux <bradgroux@hotmail.com> Signed-off-by: Brad Groux <3053586+BradGroux@users.noreply.github.com>
ec8e64c to
37b4a2f
Compare
Rebase pass — Sep 16, 2026Rebased onto current upstream main ( Rebase resultRebased cleanly onto current main. No conflicts. Still-needed assessmentNone of the 37 new main commits apply --channel to the thread root filter. Verification
What was not doneNo local test suites were run. The rebase only repositions commits; conflict resolutions carry the same logical changes forward (CI will verify builds). |
Summary
cmd_get_threadvalidates--channeland applies it to the reply filter, but the root filter (theidslookup for the thread root event itself) has no#htag. Somessages thread --channel A --event Ereturns eventEeven whenElives in a different channel — the relay's ID lookup is unscoped and returns any event matching the 64-hex ID regardless of channel.The fix adds
"#h": [channel_id]to the root filter, scoping the ID lookup to the same channel the reply filter already restricts. One line.The root filter intentionally keeps no
kindsrestriction: a thread root can be any kind (e.g. a kind:7 reaction that starts a sub-thread), and the reply filter's kind list should not constrain what the root lookup can return. The issue notes this asymmetry; it is preserved as-is.Related issue
Closes #6006
Testing
Full
buzz-clitest suite: 349 passed, 0 failed. Clippy clean. Rustfmt clean.The fix is a single-field addition to the root filter JSON. The existing test suite covers the validate-and-build path; the filter construction itself is verified by code inspection against the issue's reproduction (asking channel A for an event in channel B previously returned the event at rc=0; now the
#htag scopes the lookup to channel A).