Repo-set filter args on recall_action_required and recall_refresh #59

Open
opened 2026-05-23 20:55:28 +00:00 by coilysiren · 0 comments
Owner

Originally filed by @coilysiren on 2026-05-05T07:58:59Z - https://github.com/coilysiren/repo-recall/issues/53

Use case

A consumer driving a multi-repo build loop wants to ask "is the queue empty for the repos this step touches?" as a per-step gate. Today ActionRequiredArgs {} and RefreshArgs {} are both empty, so:

  • The consumer pulls the full action-required list and filters client-side. Fine for small N, awkward as the workspace grows.
  • A sync "refresh now" via recall_refresh rescans every repo on disk. There's no way to say "only rescan these three repos before I check the gate."

Both work around the same gap: no way to scope a call to a known repo set.

What's needed

Add an optional repo filter argument to both tools:

pub struct ActionRequiredArgs {
    /// If set, only return entries for these repo ids. Empty/None means \"all repos\".
    pub repo_ids: Option<Vec<i64>>,
}

pub struct RefreshArgs {
    /// If set, only re-scan these repo ids. Empty/None means \"full refresh\" (current behavior).
    pub repo_ids: Option<Vec<i64>>,
}

Filter on the action-required side is a one-line .filter() on the existing iteration. Filter on the refresh side is more involved (the current run_refresh is a single all-repos pass) and may not be worth shipping in the same change.

Priority

Lower than #52 (ordering contract). Consumer can filter client-side until repo count crosses some threshold. Filing now so the design intent is captured before someone adds an unrelated arg to either struct.

Acceptance

  • recall_action_required accepts an optional repo_ids filter and applies it server-side. Empty/missing = current behavior.
  • (Optionally, separate PR) recall_refresh accepts an optional repo_ids filter and rescans only those repos.
  • Both documented in the tool description so the consumer knows the filter exists without reading source.

Cross-refs

  • #52 - ordering contract on the same tool.
_Originally filed by @coilysiren on 2026-05-05T07:58:59Z - [https://github.com/coilysiren/repo-recall/issues/53](https://github.com/coilysiren/repo-recall/issues/53)_ ## Use case A consumer driving a multi-repo build loop wants to ask "is the queue empty *for the repos this step touches*?" as a per-step gate. Today `ActionRequiredArgs {}` and `RefreshArgs {}` are both empty, so: - The consumer pulls the full action-required list and filters client-side. Fine for small N, awkward as the workspace grows. - A sync \"refresh now\" via `recall_refresh` rescans every repo on disk. There's no way to say \"only rescan these three repos before I check the gate.\" Both work around the same gap: no way to scope a call to a known repo set. ## What's needed Add an optional repo filter argument to both tools: ```rust pub struct ActionRequiredArgs { /// If set, only return entries for these repo ids. Empty/None means \"all repos\". pub repo_ids: Option<Vec<i64>>, } pub struct RefreshArgs { /// If set, only re-scan these repo ids. Empty/None means \"full refresh\" (current behavior). pub repo_ids: Option<Vec<i64>>, } ``` Filter on the action-required side is a one-line `.filter()` on the existing iteration. Filter on the refresh side is more involved (the current `run_refresh` is a single all-repos pass) and may not be worth shipping in the same change. ## Priority Lower than #52 (ordering contract). Consumer can filter client-side until repo count crosses some threshold. Filing now so the design intent is captured before someone adds an unrelated arg to either struct. ## Acceptance - `recall_action_required` accepts an optional `repo_ids` filter and applies it server-side. Empty/missing = current behavior. - (Optionally, separate PR) `recall_refresh` accepts an optional `repo_ids` filter and rescans only those repos. - Both documented in the tool description so the consumer knows the filter exists without reading source. ## Cross-refs - #52 - ordering contract on the same tool.
coilysiren added
P4
and removed
P3
labels 2026-05-31 07:01:10 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/repo-recall#59
No description provided.