mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
Sami
1d7f862db6
`--depth-limit` was documented as selecting which server code path serves
the request. True, and incomplete in the direction that loses rows: the
two paths return different SETS, not the same set at different speeds.
The depth-limited path (buzz-db/src/thread.rs:422 `tm.root_event_id = $2`)
returns descendants by thread ANCESTRY, from `thread_metadata` rows the
relay writes at ingest only when an event clears two gates -- kind
(handlers/ingest.rs:612 `requires_h_channel_scope`) AND a NIP-10 marked
`e` tag (handlers/ingest.rs:745, `root_hex.is_none() && reply_hex.is_none()
-> Ok(None)`). The path without a depth bound matches on `#e` containment:
any event referencing the id, ancestry or not.
Measured on the built binary against the live relay, one channel:
- All 18 kind-40003 edits carry a 2-element bare `e` tag: kind gate
passes, marker gate fails, no ancestry row. 16 of 16 edit-carrying
roots diverge; the depth path loses all 18 edits and gains nothing.
e.g. root 3b341dac: no depth bound n=9 {9:7, 40003:2};
`--after 0` n=7 {9:7}.
- A thread requested on a mid-thread event returns that event ALONE on
the depth path (04e40378: n=4 without a depth bound -- itself plus its
3 direct children -- n=1 with any depth bound), because no ancestry
row names it as a root.
This matters for this crate specifically because `--after` implies the
depth sentinel, so the forward-paging idiom this help text recommends
switches every caller onto the ancestry path. Documenting the mechanism
rather than the observation: the two sets are not nested in either
direction by construction, since the ancestry path ignores the filter's
kinds entirely, so a kind outside the documented reply list can come back
on it and the documented list can be silently narrowed on it.
Strict subset is what this corpus shows, not an invariant: no marked
event of a kind outside the CLI's reply list exists here (only 9000
appears, 0 marked), so the gain column is empty by corpus, not by rule.
Doc-only. No behaviour change: two builds, hashes 975a2e1c vs 63542b39,
identical output over an 8-command probe (forward walks, both hazard
cells, the mid-thread event, garbage `--kinds`, a half cursor), with
`thread --help` as the positive control reporting DIFFERS so the oracle
is known to discriminate. 370 tests / 0 failed, clippy -D warnings clean.
Reported by Quinn (R119) and required before merge by Eva (R121).
Co-authored-by: Sami <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz>
Signed-off-by: Sami <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz>