Watch
0
0
Fork
You've already forked hyperhive
0

hive-forge: fetch issue comments in one request; the endpoint has no paging

The forge's issue-comments endpoint takes no page or limit and always
returns the whole thread. #5055 wrapped view's fetch in all_pages, which
never saw a short page on a thread of 50+ comments and fetched the same
list 50 times: `issue view 3782` printed 3000 comments instead of 60.
`comments --limit K` sent K as a page size the forge ignored, so it
returned the whole thread.

view and pr status's last_comment now send one request. comments fetches
the thread once and cuts the --limit / --tail window client-side; the
X-Total-Count probe and the computed-page tail walk are gone, and the
count of comments outside the window is the length of the list.
--since is unchanged.

tests/comments_no_paging.rs runs the binary against a loopback mock
forge whose comments route ignores page and limit, as Forgejo's does.
This commit is contained in:
atlas 2026-10-09 21:04:40 +02:00
commit 1d56a74aad

View file

@ -7,7 +7,7 @@ use forgejo_api::structs::{IssueGetCommentsQuery, StateType};
use crate::client::{Client, index};
use crate::notify;
use crate::verbs::{all_pages, attachment_line, issue_reactions, reaction_summary, refuse_json};
use crate::verbs::{attachment_line, issue_reactions, reaction_summary, refuse_json};
#[derive(ClapArgs)]
pub struct Args {
@ -63,15 +63,12 @@ pub fn run(client: &Client, args: Args) -> Result<()> {
println!("[reactions: {summary}]");
}
let idx = index(args.number)?;
let comments = all_pages(|page, size| {
let (_, batch) = client
.api()
.issue_get_comments(owner, name, idx, IssueGetCommentsQuery::default())
.page(page)
.page_size(size)
.send()?;
Ok(batch)
})?;
// One request: this endpoint takes no page or limit and returns the
// whole thread, so a paging loop would fetch it again on every page.
let (_, comments) = client
.api()
.issue_get_comments(owner, name, idx, IssueGetCommentsQuery::default())
.send()?;
if !comments.is_empty() {
println!();
println!("---");