Skip to content

Tracking: adopt commit/PR streaming end-to-end in downstream consumers #1337

Description

@ognis1205

Is there an existing issue or pull request for this?

  • I have searched the existing issues and pull requests

Feature description

The remote layer was recently refactored to expose commits and pull requests as streams (PR #1272). While this clears the way for smarter request strategies and performance improvements, the downstream code
still eagerly collects these streams into Vecs and processes them in a non-streaming fashion.

As a result, the current implementation does not yet benefit from:

  • early exits
  • reduced API requests

In other words, the streaming abstraction is not yet reflected end-to-end.

Desired solution

Adopt streaming semantics throughout downstream consumers so that commit and pull request data can be processed incrementally instead of being fully materialized upfront.

This issue is intended as a tracking issue, and the work can be implemented incrementally across multiple follow-up PRs.

Alternatives considered

  • Keeping the current eager collection approach and relying on pagination limits or higher rate limits
  • mplementing ad-hoc early-exit logic on top of fully collected result sets

These alternatives do not fully realize the benefits enabled by the stream-based remote refactor.

Additional context

Related PR: #1272

Activity

  1. removed their assignment
    on Jan 8, 2026
  2. orhun commented on Jan 8, 2026

    @orhun
    Owner

    One significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.

  3. ognis1205 commented on Jan 9, 2026

    @ognis1205
    ContributorAuthor

    One significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.

    Thanks for the pointer. That makes sense.

    In my case, the downstream usage I had in mind is currently contained within git-cliff-core itself, specifically around these areas:

    • let data = tokio::runtime::Builder::new_multi_thread()
      .enable_all()
      .build()?
      .block_on(async {
      let (commits, pull_requests) = tokio::try_join!(
      github_client.get_commits(ref_name),
      github_client.get_pull_requests(ref_name),
      )?;
      log::debug!("Number of GitHub commits: {}", commits.len());
      log::debug!("Number of GitHub pull requests: {}", pull_requests.len());
      Ok((commits, pull_requests))
      });
      log::info!("{}", github::FINISHED_FETCHING_MSG);
      data
    • pub fn $fn(
      &mut self,
      mut commits: Vec<Box<dyn RemoteCommit>>,
      pull_requests: Vec<Box<dyn RemotePullRequest>>,
      ) -> Result<()> {

    That said, from my personal perspective, I think there's also an option to gradually move toward a stream-based API more broadly, for example, keeping the existing non-stream-based APIs for now but marking them as #[deprecated], and transitioning incrementally.

    This would obviously need some discussion and agreement, but I wanted to put it on the table as a possible direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions