Pagination 구현: GitHub GraphQL API 에 Issue 요청 및 응답 파싱시 Pagination 하도록 구현

[JonghoKim-jj]

#181 의 하위 작업으로서 생성합니다.

[sophie-cluml]

이 작업은 작업 진행 방향(설계) 에 대한 것을 제안하는 것이 좋을 것 같습니다. @JonghoKim-jj 별도 채널에서 이 이슈를 진행하고자하는 의사를 저에게 전달주셨는데요, 생각하신 진행 방향(설계) 에 대한 아이디어를 간략하게 글, 표 등으로 제시해주실 수 있을까요?

[JonghoKim-jj]

문제

이미 알고 계시겠지만, 현재 paging 이 구현되어 있지 않아 여러 문제가 있습니다.

• default page size 이상의 item 을 가져와야 하는 경우 (ex) 현재 issue 10 개 넘으면 한 번에 request 못함
• .graphql 파일에 page size 하드코딩 (ex)

  github-dashboard-server/src/outbound/graphql/issues.graphql

  Lines 49 to 50 in 61d2bad

  	# TODO: #181
  	comments(last: 100) {

GitHub GraphQL API 의 Rate Limiting 정책

GitHub Rate Limitation 에 나와있습니다.

• GitHub Primary Rate Limit
  • 각 노드에 대한 page size 는 반드시 1-100 범위의 값. 반드시 값을 제공해야 함 (즉, 반드시 pagination parameter 가 있어야 함)
  • 한 종류의 노드 한 요청당 최대 100 개
  • 모든 노드 갯수 한 요청당 최대 500k 개
• GitHub Secondary Rate Limit
  • points 관련 규칙이 존재함. read-only request 는 일반적인 user 의 경우 60분당 5000 points 사용 가능
  • read-only request 기준으로, 모든 노드 갯수를 100 으로 나눈 후 round 한 값이 points 임
  • 공격적으로 fetching 할 경우 secondary rate limit 을 세밀하게 고려해야 하지만, 다소 복잡하므로 이 이슈에서 다루지 않는 것을 목표로 함

제안하는 구현안

선행조건: Related Issues

요청 및 재요청하는 코드를 단순화하기 위해, #185 를 main branch 에 merge 한 이후에 작업을 시작하는 것이 좋다고 생각합니다.
특히 src/outbound.rs 의 fn send_github_issue_query 를 단순화하기 위해 필요하다고 생각합니다.

노드별 적절한 default page size 설정

• 노드별로 추가적인 요청을 최대한 피하도록 default page size 를 설정. 노드의 갯수가 대부분 또는 항상 특정 값을 넘지 않을 것으로 예상될 경우 해당 값을 default page size 로 설정함
  • issue: 100. repo 를 제외하면 최상위 노드이므로 maximum page size 인 100 으로 설정함
  • issue.assignees: 2. 대부분 이슈에서 0-1명의 assignee 를 가지며, 3명 이상의 assignee 는 거의 없을 것으로 예상
  • issue.labels: 5. github-dashboard-server 의 경우 라벨이 11개이며, 5개 이상 하나의 이슈에 붙는 경우는 거의 없을 것으로 예상함
  • issue.comments: 20. comment 가 20개보다 많은 경우가 있으나, GitHub secondary rate limit points 를 아끼기 위해 20 으로 설정함
  • issue.projectItems: 3. 현재 aicers 의 project item 은 "to-do list", private project items 포함하여 3개뿐이므로, 3개보다 많게 될 일이 없음
  • issue.subIssues: 10. 대부분의 경우 sub-issue 갯수가 10 개를 넘지 않을 것으로 예상함
  • issue.closedByPullRequestsReferences: 1. 자동으로 이슈를 닫은 PR 의 경우 보통 0-1 개임. 2개 이상이려면, close 된 이슈를 re-open 한 후 다른 PR 이 이슈를 다시 닫아야 하는데, 이러한 경우는 거의 없을 것으로 예상하여 1로 설정
• TOTAL NODE: 4.2k. 1개의 repo 당 요청 시 최대 4.2k 개의 노드 조회
• POINTS (GitHub secondary rate limit): 42 points. 4.2k / 100 = 42 이므로 42 points 로 계산함. 현재처럼 5분에 1번씩 요청하는 것을 기준으로 한다면, 5분당 1번씩 5개의 repository 에 요청하면 60분에 2520 points 사용. 60분당 5000 points 사용가능하다는 점에 근거할 때, default page size 보다 노드가 많을 경우 추가 요청으로 points 소모가 늘어나는 것을 고려해도, points 가 넉넉할 것으로 예상

total node 가 4.2k 라는 것은 아래 GraphQL query 로 확인 가능합니다.
아래와 같이 GitHub GraphQL API 에 요청해보았습니다:

query Issues(
  $owner: String!
  $name: String!
  $since: DateTime
  #
  # Paging Parameters for an Issue.
  # Supports both forward and backward paging
  #
  $after: String
  $first: Int
  $before: String
  $last: Int
  #
  # Paging Parameters for an issue's properties.
  # Currently supports backward paging only
  #
  $assignee_page_offset: String
  $assignee_pagesize: Int = 2
  $labels_page_offset: String
  $labels_pagesize: Int = 5
  $comments_page_offset: String
  $comments_pagesize: Int = 20
  $project_items_page_offset: String
  $project_items_pagesize: Int = 3
  $subissues_page_offset: String
  $subissues_pagesize: Int = 10
  $closing_prs_page_offset: String
  $closing_prs_pagesize: Int = 1
) {
  rateLimit {
    cost
    limit
    nodeCount
    remaining
    resetAt
    used
  }

  repository(owner: $owner, name: $name) {
    issues(
      after: $after
      first: $first
      before: $before
      last: $last
      filterBy: { since: $since }
    ) {
      pageInfo {
        # Forward Paging Cursor
        hasNextPage
        endCursor
        # Backward Paging Curosr
        hasPreviousPage
        startCursor
      }
      nodes {
        id
        number
        title
        body
        state
        closedAt
        createdAt
        updatedAt
        author {
          __typename
          ... on User {
            login
          }
        }
        assignees(before: $assignee_page_offset, last: $assignee_pagesize) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          nodes {
            login
          }
        }
        labels(before: $labels_page_offset, last: $labels_pagesize) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          nodes {
            name
          }
        }
        comments(before: $comments_page_offset, last: $comments_pagesize) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          nodes {
            author {
              __typename
              ... on User {
                login
              }
            }
            body
            createdAt
            id
            repository {
              name
            }
            updatedAt
            url
          }
        }
        projectItems(
          before: $project_items_page_offset
          last: $project_items_pagesize
        ) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          nodes {
            __typename
            id
            todoStatus: fieldValueByName(name: "Status") {
              __typename
              ... on ProjectV2ItemFieldSingleSelectValue {
                name
              }
            }
            todoPriority: fieldValueByName(name: "Priority") {
              __typename
              ... on ProjectV2ItemFieldSingleSelectValue {
                name
              }
            }
            todoSize: fieldValueByName(name: "Size") {
              __typename
              ... on ProjectV2ItemFieldSingleSelectValue {
                name
              }
            }
            todoInitiationOption: fieldValueByName(name: "Initiation Options") {
              __typename
              ... on ProjectV2ItemFieldSingleSelectValue {
                name
              }
            }
            todoPendingDays: fieldValueByName(name: "Pending days") {
              __typename
              ... on ProjectV2ItemFieldNumberValue {
                number
              }
            }
          }
        }
        subIssues(before: $subissues_page_offset, last: $subissues_pagesize) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          nodes {
            id
            number
            title
            state
            closedAt
            createdAt
            updatedAt
            author {
              __typename
              ... on User {
                login
              }
            }
          }
        }
        parent {
          id
          number
          title
        }
        url
        closedByPullRequestsReferences(
          before: $closing_prs_page_offset
          last: $closing_prs_pagesize
        ) {
          totalCount
          pageInfo {
            hasPreviousPage
            startCursor
          }
          edges {
            node {
              number
              state
              closedAt
              createdAt
              updatedAt
              author {
                __typename
                ... on User {
                  login
                }
              }
              url
            }
          }
        }
      }
    }
  }
}

아래와 같이 응답이 옵니다:

{
  "data": {
    "rateLimit": {
      "cost": 6,
      "limit": 5000,
      "nodeCount": 4200,
      "remaining": 4921,
      "resetAt": "2025-08-19T04:44:37Z",
      "used": 79
    },
    "repository": {
      ...
    }
  }
}

data 섹션에 있는 rateLimit.nodeCount 가 total node 갯수입니다.

간단한 구현안

1. 기존 GraphQL query 를 수정 & 새로운 GraphQL query 추가
   • 기존 GraphQL 요청은 하드코딩된 page size 만큼 요청하므로 이를 수정하여 하드코딩 제거
   • issue 에 연결된 한 종류의 노드만 추가요청할 수 있도록 GraphQL query 추가: assignees, labels, comments, projectItems, subIssues, closedByPullRequests
2. 기존 outbound (GitHub API) 요청 및 응답 처리 로직에 pagination 로직 추가
   • 첫 요청은 issue 및 각 노드들을 default page size 만큼 요청
   • 응답에 포함된 cursor 들을 파싱 & 필요시 재요청하여 기존 노드 목록에 append 하는 로직 추가
     • issue 는 forward/backward paging 을 모두 지원하고, GraphQL query 및 코드 단순화를 위해 issue 에 연결된 노드들은 forward paging 만 지원
     • hasNextPage == true 인 경우, Forward Paging 을 요청하였고 남은 페이지가 있는 것이므로 endCursor 이용하여 재요청
     • hasPreviousPage == true 인 경우, Backward Paging 을 요청하였고 남은 페이지가 있는 것이므로 startCursor 이용하여 재요청
     • hasNextPage == false && hasPreviousPage == false 인 경우 남은 페이지가 없는 것이으므로 재요청할 필요 없음

기존 GraphQL 문법의 한계로 인해 mutually exclusive 한 필드들을 표현할 때 제약사항을 제대로 걸지 못합니다.
최근 GraphQL 에 @oneOf directive 가 추가되긴 했지만, GitHub GraphQL API 는 이를 사용하고 있지 않습니다.

이에 비해 Rust 의 enum 을 이용한다면 mutually exclusive 한 필드들을 잘 처리할 수 있을 것으로 생각합니다.
예를 들어 pagination parameter 를 생각해볼 수 있습니다.

// pseudo-code for pagination parameters

type Cursor = String;
type PageSize = u8;

enum PageParams {
    ForwardPageParams(Option<Cursor>, PageSize), // will be converted to GraphQL fields { first: xx, after: xx }
    BackwardPageParams(Option<Cursor>, PageSize), // will be converted to GraphQL fields { last: xx, before: xx }
}

(TODO) 복잡한 구현

아래 기능들은 다소 복잡할 것으로 예상되어, 다른 이슈에서 해결하고자 합니다.

• (매우) 자원효율적인 pagination
• GitHub GraphQL API 의 rate limit 상태를 모두 고려한 pagination
• toml 파일에서 값을 읽어 default page size 설정

[danbi2990]

노드별 적절한 default page size 설정

필드별로 적정값을 관리하는 것보다 max 값인 100으로 통일하는게 어떨까요? 재요청할 때도 100으로 통일하는게 심플해보입니다.

만약 가져오지 않아도 되는 필드가 잔뜩 있는 경우 page size를 제한하는 것이 유의미해 보입니다. 저희는 어차피 모두 가져와야하는 정보라서 page size 제한이 크게 유의미해 보이진 않습니다.

issue 에 연결된 한 종류의 노드만 추가요청할 수 있도록 GraphQL query 추가: assignees, labels, comments, projectItems, subIssues, closedByPullRequests

각각의 노드별로 쿼리를 추가한다는 의미인가요? 기존의 쿼리에 불필요한 노드의 파라미터 first에 0을 줘서 필드를 호출하지 않는 방법이 가능해 보입니다.

문제는 issue에 Scalar로 선언된 number, title, body 같은 필드들로 보입니다. 이것들은 파라미터를 통해서 제외할 수 없으므로 효율적인 rate limit을 위해선 이것들을 제외한 쿼리를 하나 더 추가하는 방법이 가능해 보입니다.

즉, 처음 호출하는 쿼리, 재호출하는 쿼리 두 종류로 나뉠 수 있어 보입니다. 만약 첫호출, 재호출 쿼리를 다르게 했을 때 append 하는 로직이 복잡해진다면 재호출 쿼리에 중복된 필드(number, title, body 등)이 있더라도 이를 감수하고 동일한 쿼리를 재사용하는 방식도 가능해 보입니다.

$assignee_page_offset: String
$assignee_pagesize: Int = 2
$labels_page_offset: String
$labels_pagesize: Int = 5
$comments_page_offset: String
$comments_pagesize: Int = 20
$project_items_page_offset: String
$project_items_pagesize: Int = 3
$subissues_page_offset: String
$subissues_pagesize: Int = 10
$closing_prs_page_offset: String
$closing_prs_pagesize: Int = 1

일관성을 위해서 page_offset, pagesize 대신 after, first 를 사용하는 게 어떨까요?

before: $assignee_page_offset, last: $assignee_pagesize

before, last 가 아니라 after, first를 사용해야될 것 같습니다. 아마 기존 코드에 last가 사용됐던 것 같은데 paging할 땐 after, first가 편할 것 같아요.

issue 는 forward/backward paging 을 모두 지원

backward 를 지원해야될까요? 얼핏 생각하기론 forward만 되도 될 것 같아서요.

[JonghoKim-jj]

저희가 Issue 요청 시 조회하는 노드는 아래와 같은 7종류입니다.

1. issue
2. issue.assignees
3. issue.labels
4. issue.comments
5. issue.projectItems
6. issue.subIssues
7. issue.closedByPullRequestsReferences

필드별로 적정값을 관리하는 것보다 max 값인 100으로 통일하는게 어떨까요? 재요청할 때도 100으로 통일하는게 심플해보입니다.

첫 요청시에 요청할 page size 는 신중히 결정하는게 이득이라 생각합니다.
모든 노드의 page size 를 100 으로 통일하면 심플하긴 합니다만, 모든 노드의 page size 를 100 으로 요청할 경우, 최대 60100개의 노드를 조회할 가능성이 있는 GraphQL query 로서 판단되어, GitHub rate limit points 를 601 points 소모합니다. 60분마다 5000 points 를 쓸 수 있는데, 1개의 repository 에 대해 기존처럼 5분마다 한 번씩 요청해도 60분이면 7212 points 를 소모하여 rate limit 을 크게 넘게 됩니다.

저도 issue, issue.comments 는 page size 를 max 값인 100으로 만들거나 충분히 큰 숫자로 설정해주는게 합리적이라고 생각합니다. 그러나 나머지 노드들은 page size 가 100 에 가까우면 GitHub rate limit points 를 상당히 크게 낭비한다고 생각합니다. 예를 들어, 저는 하나의 이슈에 assignee 가 20~100명씩 할당되는 use case 는 없으리라 생각하고 있습니다.

제안주신대로 재요청할 때 page size 를 100 으로 통일하는 방식은 심플해서 좋다고 생각합니다.
제가 예상할 때 pagination 에 의해 재요청이 들어갈 노드는 대부분 issue 일 것이고, 다른 노드들에 대해서는 재요청이 자주 일어나진 않을 것이라 예상하고 있습니다.
GitHub rate limit points 를 낭비하기 싫다면 totalCount 필드를 조회하고 이에 따라 page size 를 조정하면 낭비하는 rate limit points 를 없앨 수 있지만, 당장 이 이슈에서는 굳이 그정도까지 최적화를 하지 않고 심플하게 구현하는게 좋을 것 같습니다.

각각의 노드별로 쿼리를 추가한다는 의미인가요? 기존의 쿼리에 불필요한 노드의 파라미터 first에 0을 줘서 필드를 호출하지 않는 방법이 가능해 보입니다.

문제는 issue에 Scalar로 선언된 number, title, body 같은 필드들로 보입니다. 이것들은 파라미터를 통해서 제외할 수 없으므로 효율적인 rate limit을 위해선 이것들을 제외한 쿼리를 하나 더 추가하는 방법이 가능해 보입니다.

즉, 처음 호출하는 쿼리, 재호출하는 쿼리 두 종류로 나뉠 수 있어 보입니다. 만약 첫호출, 재호출 쿼리를 다르게 했을 때 append 하는 로직이 복잡해진다면 재호출 쿼리에 중복된 필드(number, title, body 등)이 있더라도 이를 감수하고 동일한 쿼리를 재사용하는 방식도 가능해 보입니다.

@danbi2990 께서 제안해주신 것처럼 재호출할 때 필요없는 노드들의 first 를 0으로 설정하면 될 것 같습니다.
제가 처음에 first 에 0 값이 들어가지 못하는 것으로 오해해서 GraphQL query 를 여러개 작성할까 생각했었습니다. 예를 들어 issue.comments 만 새로 fetch 해오는 GraphQL query 를 작성하는 것입니다. 저는 GitHub 문서 설명에서 page size 가 1-100 사이의 값이라길래 저는 first 에 0 값이 불가한 줄 오해했는데, first 에 0을 넣고 요청해보니까 응답이 잘 오네요. 기존 GraphQL query 를 수정해서 쓰면 될 것 같습니다.

참고로 number, title, body 같은 scalar 필드들의 조회 여부는 GitHub rate limit 에 전혀 영향을 미치지 않습니다.
조회하는 노드의 갯수 (issue, issue.comments, ...) 만 rate limit 에 영향을 줍니다.

일관성을 위해서 page_offset, pagesize 대신 after, first 를 사용하는 게 어떨까요?

일관성을 위해 after, first 로 통일하여 사용하겠습니다.

backward 를 지원해야될까요? 얼핏 생각하기론 forward만 되도 될 것 같아서요.

issue 포함 모든 노드에 대해 forward paging 만 해도 좋을 것 같습니다.
GraphQL 및 Rust 코드가 단순해지는게 좋다고 생각합니다.

[danbi2990]

넵 괜찮아 보입니다.

[JonghoKim-jj]

@sophie-cluml 논의가 어느정도 진행되어 정리드립니다.

설계 주안점

• GitHub Rate Limitation 에 기재된 GitHub Primary Rate Limitation, GitHub Secondary Rate Limitation 조건에 위배되지 않도록 pagination 설계 (만약 위배 시 request reject 됨)
• 최대한 단순/간단한 구현안을 제시하여, 가장 큰 문제인 (1) fetch 가 느리다는 점 및 (2) GitHub 에 요청하는 outbound GraphQL query 가 하드코딩 되어 있는다는 점을 해결

Default Page Size

default page size 는 아래와 같이 정함

노드	default page size	선정 이유
issue	100	요청 횟수를 최소화하기 위해 max 로 설정
issue.assignee	2	assignee 가 3명 이상인 경우는 거의 없을 것으로 예상
issue.labels	5	이 repository 에 label 은 11 종류인데, 6개 이상 사용하는 경우는 거의 없을 것으로 예상
issue.comments	100	comment 가 많이 달리는 경우가 있어, 요청횟수를 최소화하기 위해 max 로 설정
issue.projectItems	3	현재 aicers organization 의 project 는 "to-do list" 를 포함하여 3개임. 현재 aicers organization 에 repository 에issue.projectItems 가 4개 이상 존재하는 것이 불가능함
issue.subIssues	10	특정 이유에 sub issue 가 11개 이상 있는 경우는 거의 없을 것으로 예상
issue. closedByPullRequestsReferences	1	특정 이슈를 closing 하는 PR 이 2개 이상 존재하는 경우는 거의 없을 것으로 예상

위와 같이 page size 를 설정하여 요청할 경우, GitHub secondary rate limit points 를 122 points 를 소비함.
60분에 5000 points 주어지므로, 예를 들어, 3개 repo 에 대해 각각 5분에 1번씩 요청할 경우 3 x 12 x 122 = 4392 points 소모함. 추가요청이 있을 것을 가정해도 넉넉할 것으로 예상됨

Pagination 방식

1. 첫 요청은 default page size 만큼 요청
   • 로직 단순화를 위해 모든 노드에 대해 forward paging 방식으로 요청함
2. 첫 요청의 응답을 파싱
   • 노드 정보, 페이징 정보 (페이징 커서)를 얻을 수 있음
3. 페이징 커서의 hasNextPage 가 true 인 경우 재요청
   • 추가 요청 시 page size 는 100 으로 설정. 이는 재요청 횟수를 줄이고 로직을 최대한 단순화 하기 위함.
   • 가정: default page size 선정 기준을 고려할 때, issue 를 제외한 다른 노드에 대해 재요청하는 경우는 거의 없을 것으로 예상
   • 만약 재요청이 빈번하거나 GitHub secondary rate limit 에 걸리게 되면 설계의 우선순위를 "로직의 단순화" 에서 "GitHub secondary rate limit 의 낭비를 없애는 것" 으로 변경해야 함

TODOs

현재 이슈에서 다루기에 복잡하여 제외했으나, 아래 기능들은 다른 이슈에서 추후 진행했으면 좋겠습니다.

• (매우) 자원효율적인 pagination 로직
• GitHub GraphQL API 의 rate limit points 를 낭비하지 않는 pagination 로직 (현재 이슈에서 제안한 방식은 3개보다 많은 repository 에 대해 5분에 1번 이상 요청하기 쉽지 않음)
• toml 파일에서 값을 읽어 default page size, outbound (GitHub) fetch period 설정

[sophie-cluml]

다음과 같은 문의 및 제안이 있습니다.

예를 들어, 3개 repo 에 대해 각각 5분에 1번씩 요청할 경우 3 x 12 x 122 = 4392 points 소모함. 추가요청이 있을 것을 가정해도 넉넉할 것으로 예상됨

계산에서, 리포가 4개 되면 안 넉넉한 상황 같아보이는데, 어떤 측면에서 넉넉하다고 보셨는지 궁금합니다.

추가 요청 시 page size 는 100 으로 설정.

이보다는 default page size를 지속 유지하는 방향을 제안하고 싶습니다. 이슈에서 논의된 사항을 토대로, 한 번에 다 가져올 가능성이 매우 높은 값으로 default page size 값을 선정해주신 것으로 이해하고 있습니다. 그렇다면 두 번 가져온다면 정말 더 이상 페이징이 더 일어나지 않고 두번째 paging 요청에서 다 가져올 가능성이 매우 높을 것 같습니다. 물론 아웃라이어 케이스는 있겠으나, default page size 를 선정할 때의 전제를 다음 페이징 요청에서도 동일하게 전제하는 것이 baseline을 심플하게 깔아주는 데에 유리하다고 생각합니다.

현재 이슈에서 다루기에 복잡하여 제외했으나, 아래 기능들은 다른 이슈에서 추후 진행했으면 좋겠습니다.

무조건 진행한다기보다 우선 현재 이슈에서 구현하고 도입한 이후 상황을 지켜보고 방향을 결정하는 것이 좋을 것 같습니다.

[JonghoKim-jj]

@sophie-cluml

issue 를 제외한 노드 재요청 시 Rate Limit Points 소모는 작음

의견주신 부분들에 대해 논의하기 전에 제가 생각한 바에 대해 공유드립니다.

issue 를 제외한 다른 노드에 대해 재요청이 필요할 경우, issue 의 page size 를 1로 놓고 나머지 6종류 노드의 page size 를 모두 최대인 100 으로 설정하여 재요청한다고 가정해도, GitHub rate limit point 낭비가 최대 6 points 라 그리 크지 않긴 합니다. (c.f. 첫 요청이 122 points 소모)

이 생각에 착안하여 재요청 로직을 단순하게 설계해도 될 것이라 판단했습니다.

재요청 시 page size

이보다는 default page size를 지속 유지하는 방향을 제안하고 싶습니다. 이슈에서 논의된 사항을 토대로, 한 번에 다 가져올 가능성이 매우 높은 값으로 default page size 값을 선정해주신 것으로 이해하고 있습니다. 그렇다면 두 번 가져온다면 정말 더 이상 페이징이 더 일어나지 않고 두번째 paging 요청에서 다 가져올 가능성이 매우 높을 것 같습니다. 물론 아웃라이어 케이스는 있겠으나, default page size 를 선정할 때의 전제를 다음 페이징 요청에서도 동일하게 전제하는 것이 baseline을 심플하게 깔아주는 데에 유리하다고 생각합니다.

제안해주신 방식이 최대한 단순한 로직으로 가기에 좋네요.
그나마 아웃라이어라면 issue 인 경우가 재요청이 2회 이상인 경우가 제일 많을 것으로 예상되는데,
default page size 를 최대치로 잡았기 때문에 문제되지 않을 것 (효율적일 것) 이라 예상합니다.

재요청 시 issue 노드의 page size 를 1로 설정하고 나머지 노드의 page size 를 제안 주신대로 default page size 로 설정하면, GitHub rate limit points 를 1 point (!!) 만큼 소모합니다. 첫 요청이 122 points 소모하는 것을 감안하면 첫 요청의 1% 도 안 되는 rate limit 을 소모합니다.

리포가 4개 이상인 경우

계산에서, 리포가 4개 되면 안 넉넉한 상황 같아보이는데, 어떤 측면에서 넉넉하다고 보셨는지 궁금합니다.

제가 언급한 조건 대로 리포가 3개 이하, 5분에 1번 이상 요청을 보내지 않는다는 전제면 넉넉하지 않습니다.
제가 너무 로직을 단순하게 만드는데 과도하게 집중해서, 너무 강한 전제를 했다는 생각이 드네요.

보완할 수 있는 방식을 제안해보면 아래와 같습니다:

• [대안1] rate limit points 가 reset 되는 시점까지 중지 후 재개
  • 매 요청/재요청마다 rateLimit.remaining, rateLimit.resetAt 정보를 노드 정보와 같이 fetch 합니다. rateLimit 요청에는 추가적인 rate limit points 소모가 없기 때문에 나름대로 합리적입니다.
  • rateLimit.remaining 이 0 인 경우, rateLimit.resetAt 시점까지 대기 후 다시 요청을 재개합니다.
• [대안2] 가진 rate limit points 를 리포 갯수로 나누어 요청 빈도를 조절
  • 모든 리포에 대해 동등한 횟수만큼 첫 요청. (122 points each)
  • issue 를 제외한 다른 노드에 재요청이 필요할 시에는 필요한 만큼 재요청. (1 point each)
• [대안3] total counts 및 이미 fetch 한 노드 갯수에 의거하여 리포별로 다른 요청 빈도를 적용
  • issue, issue.comments 등 노드들은 모두 totalCount 필드가 존재합니다. 이미 fetch 한 노드 갯수에 비해 totalCount 숫자가 높은 리포/노드에 대해 요청빈도를 늘려줄 수 있습니다.
  • fetch 한 노드 갯수를 관리해야해서 로직이 다소 복잡해질 것으로 예상되긴 합니다.
  • issue 노드에 대해 (totalCount) - (이미 fetch 한 issue 갯수) 가 높은 리포부터 요청을 수행하는게 가장 단순하고 확실할 것 같습니다.

제시한 대안들이 서로 배타적이지 않아 모두 적용가능하긴 한데,
제 생각에는 [대안1] 과 [대안2] 정도를 현재 이슈에서 채택하면 어떨까 합니다.

TODO 제안

무조건 진행한다기보다 우선 현재 이슈에서 구현하고 도입한 이후 상황을 지켜보고 방향을 결정하는 것이 좋을 것 같습니다.

다음 이슈의 TODO 부터 생각하기 보다는 현재 이슈에 일단 집중하고 추후 상황을 지켜겠습니다.

[sophie-cluml]

"issue 를 제외한 다른 노드에 대해 재요청이 필요할 경우, issue 의 page size 를 1로 놓고 나머지 6종류 노드의 page size 를 모두 최대인 100 으로 설정하여 재요청한다." 인 것이었군요. 이해되었습니다. 이에 대한 질문으로, 그렇다면 issue 그 자체에 대한 next page 에 대한 요청이 필요한 경우, #204 (comment) 에 적어주신 default page size 컬럼의 값 사용하는 방향으로 생각하시는 것이죠?

한편, 현재 main branch에서 어떤 인터벌 단위로 폴링하나요? 5분에 1회 인가요?

[JonghoKim-jj]

"issue 를 제외한 다른 노드에 대해 재요청이 필요할 경우, issue 의 page size 를 1로 놓고 나머지 6종류 노드의 page size 를 모두 최대인 100 으로 설정하여 재요청한다." 인 것이었군요. 이해되었습니다. 이에 대한 질문으로, 그렇다면 issue 그 자체에 대한 next page 에 대한 요청이 필요한 경우, #204 (comment) 에 적어주신 default page size 컬럼의 값 사용하는 방향으로 생각하시는 것이죠?

네 정확히 맞습니다.

한편, 현재 main branch에서 어떤 인터벌 단위로 폴링하나요? 5분에 1회 인가요?

저도 5분에 1번 요청인 줄 알았는데, 확인차 코드를 보니 60분에 한 번 fetch 하되, 실패하면 retry 하는게 5분마다 하도록 설정되어 있네요.

src/main.rs 에는 아래와 같이 구현되어 있습니다.

github-dashboard-server/src/main.rs

Lines 40 to 48 in 3c769ee

	// Fetches issues and pull requests from GitHub every hour, and stores them
	// in the database.
	task::spawn(outbound::fetch_periodically(
	Arc::clone(&repositories),
	settings.certification.token,
	time::Duration::from_secs(ONE_HOUR),
	time::Duration::from_secs(FIVE_MIN),
	database.clone(),
	));

Issue, PR, discussion 에 대해 모두 동일한 방식으로 fetch 하므로 Issue 를 fetch/retry 하는 로직만 예로 들겠습니다.
Issue 에 대한 주기적인 fetch 및 retry 로직의 일부는 아래와 같습니다.

github-dashboard-server/src/outbound.rs

Lines 170 to 187 in 3c769ee

	let mut re_itv = time::interval(retry);
	loop {
	re_itv.tick().await;
	match send_github_issue_query(&repoinfo.owner, &repoinfo.name, &since, &token).await
	{
	Ok(resps) => {
	if let Err(error) = db.insert_issues(resps, &repoinfo.owner, &repoinfo.name)
	{
	error!("Problem while insert Fjall Database. {}", error);
	}
	break;
	}
	Err(error) => {
	error!("Problem while sending github issue query. Query retransmission is done after 5 minutes. {}", error);
	}
	}
	itv.reset();
	}

위의 코드를 아래처럼 단순화하여 생각해볼 수 있습니다:

loop {
    re_itv.tick().await;

    // Fetch issues, break the loop if success

    itv.reset();
}

itv 는 60분 주기의 fetch 인터벌이고, re_itv 는 5분 주기의 retry 인터벌입니다.
에러가 나서 break; 되지 않을 경우에는 itv 를 리셋하고 retry 합니다.

이 코드 작성 당시의 의도를 잘 모르긴 합니다만,
현재 GitHub rate limit 관점에서 생각해보면
요청이 성공하든 에러가 나든 GitHub 의 rate limit 은 60분마다 새로 충전됩니다.
현재 이슈에서 itv.reset(); 부분을 없애면 좋겠습니다.

[sophie-cluml]

현재 남아있는 논의의 마지막 초점은 Rate Limit Point 를 현실적이면서도 올바르게 추정하는데에 있습니다.즉, itv.reset() 이 버그냐 아니냐, 혹은 구체적으로 어떤 fetch 방식을 취하고 있느냐는 현재 논의 레벨과 비교하여 매우 세부적인 토픽입니다. 이 정보는 현재의 논의에서 필요치 않습니다.

제안해주신 Default Page Size와 issue를 제외한 노드에 대해 재요청할 때의 page size를 전제한 상태로, 논의의 초점인 Rate Limit Point 를 현실적이면서도 올바르게 추정하기 위해 필요한 것은 아래 두가지 값입니다.

(1) 몇분마다 fetch 하는지
(2) fetch 대상 레포가 몇개인지

위 두가지 값과 "Default Page Size와 issue를 제외한 노드에 대해 재요청할 때의 page size" 가 결합될 때, 그 때 추정되는 Rate Limit Point 는 몇인지를 대략적으로 계산할 수 있다고 보입니다.

[JonghoKim-jj]

제안해주신 Default Page Size와 issue를 제외한 노드에 대해 재요청할 때의 page size를 전제한 상태로, 논의의 초점인 Rate Limit Point 를 현실적이면서도 올바르게 추정하기 위해 필요한 것은 아래 두가지 값입니다.

(1) 몇분마다 fetch 하는지
(2) fetch 대상 레포가 몇개인지

(1) 60분마다 fetch 합니다. (실패 시 5분마다 성공할 때 까지 retry)
(2) fetch 대상 레포는 사용자가 결정하게 됩니다. 즉, 개수 자체는 무제한입니다. https://github.com/aicers/github-dashboard-server?tab=readme-ov-file#configuration-example 처럼 설정합니다.

저는 현재 저희 목표가 aicers organization 에 대해 통계를 내는 것으로 이해했습니다.
그렇다면 유한한 rate limit point 를 갖고 무제한인 레포 갯수로 잡기보다는,
aicers organization 에서 활발히 유지보수 또는 개발중인 public/private 레포들이 대상일 것으로 생각합니다.

[JonghoKim-jj]

public repo 에 대한 개략적인 Rate Limit Point 산출 예시

private repo 는 전부 제외하고 public repo 만 예로 들겠습니다.

rate limit point 관련 리마인더 드라자면,
rate limit point 는 60분마다 5000 points 씩 주어집니다. 기존에 쓰지 않고 남아있는 point 는 없어집니다.
이슈를 100개씩 fetch 하는 첫 요청을 보낼 때 122 points 를 소모하고, 재요청이 필요하면 조금 더 소모됩니다 (재요청당 1 point)

giganto 의 경우 이슈 갯수가 약 380개이므로, 이슈 100개씩 4번 요청을 보내면 첫 요청은 완료됩니다.
즉, 첫 요청에 4번 x 122 points = 488 points 소모됩니다.
review-web 의 경우 이슈가 약 300개를 조금 넘으므로, 마찬가지로 첫 요청에 488 points 소모됩니다.
giganto + review-web 의 경우 첫 요청으로 966 points 가 소모되고, 조만간 giganto 이슈 갯수가 400개를 넘으면 첫 요청으로 1088 points 가 소모될 것으로 예상합니다.

제가 생각할 때는 당장은 rate limit point 가 넉넉할 것으로 예상합니다.
만약 첫 60분에 모두 fetch 하지 못해도 두번째 60분 동안 모두 fetch 할 수 있을 것이고 큰 문제 없을 것으로 예상합니다.

p.s.
(현재 이슈의 scope 은 아니지만) 추후 PR, Discussion 등을 fetch 하는 것도 rate limit point 를 소모하므로, 미래에는 rate limit point 가 모자라질 것으로 예상합니다. 이는 현재 이슈의 parent issue 인 #181 등 다른 이슈에서 다루면 좋겠습니다.

[sophie-cluml]

aicers organization 에서 활발히 유지보수 또는 개발중인 public/private 레포들이 대상일 것으로 생각합니다.

이게 몇개인지 세어주세요. 대략 10개, 20개, 30개, 40개 중 무엇인지 파악해주세요.