Follow-ups from #244 (PR #248), both verified as real but declined there with reasoning; neither is a regression, both are residual cases of the same class #244 fixed.
1. A legacy explicit-selection job journals every shareable identity
A job whose selection names specific sources or sessions still holds a history_subscriptions row with source IS NULL, so the capture predicate treats it as interested in every identity and selected() filters at prepare. The probe's own modes are exact (all = every source; new/selected are session jobs), so this affects a legacy explicit-selection job until it is adopted.
Narrowing needs either several subscription rows per job (history_subscriptions holds one (source, session_id) and is keyed by job id) or the selection JSON evaluated in SQL.
2. Split memberships retain undeliverable relationship revisions
When two different jobs subscribe to each endpoint of an edge, the two interested arms of the relationship predicate are satisfied between them, while record_allowed requires both endpoints in one job. The revision is journaled and always suppressed at prepare.
Correlating the arms to a single subscription is not cheap today: core cannot see which job owns a member subscription — history_subscriptions has no job column, a member row's id is the member id, and ownership lives in delivery_session_members.job_id, a plugin table the capture triggers must not read (ai-hist builds --no-default-features in CI and the triggers must work on a core-only database). It needs an owner column plus cross-boundary population and a migration.
Residue is bounded: one row per revision, for split-endpoint edges only, reclaimed on the parent job's next prepare.
Acceptance
- A source- or session-limited job journals only identities its selection can deliver.
- An edge whose endpoints belong to different jobs is not journaled.
- No capture trigger reads a plugin-owned table;
cargo build -p ai-hist --no-default-features still passes.
Follow-ups from #244 (PR #248), both verified as real but declined there with reasoning; neither is a regression, both are residual cases of the same class #244 fixed.
1. A legacy explicit-selection job journals every shareable identity
A job whose selection names specific sources or sessions still holds a
history_subscriptionsrow withsource IS NULL, so the capture predicate treats it as interested in every identity andselected()filters at prepare. The probe's own modes are exact (all= every source;new/selectedare session jobs), so this affects a legacy explicit-selection job until it is adopted.Narrowing needs either several subscription rows per job (
history_subscriptionsholds one(source, session_id)and is keyed by job id) or the selection JSON evaluated in SQL.2. Split memberships retain undeliverable relationship revisions
When two different jobs subscribe to each endpoint of an edge, the two
interestedarms of the relationship predicate are satisfied between them, whilerecord_allowedrequires both endpoints in one job. The revision is journaled and always suppressed at prepare.Correlating the arms to a single subscription is not cheap today: core cannot see which job owns a member subscription —
history_subscriptionshas no job column, a member row's id is the member id, and ownership lives indelivery_session_members.job_id, a plugin table the capture triggers must not read (ai-histbuilds--no-default-featuresin CI and the triggers must work on a core-only database). It needs an owner column plus cross-boundary population and a migration.Residue is bounded: one row per revision, for split-endpoint edges only, reclaimed on the parent job's next prepare.
Acceptance
cargo build -p ai-hist --no-default-featuresstill passes.