Excessive duplicate GitHub API requests causing inefficiency

[yegor256]

We send too many API requests to GitHub, often repeatedly. For example, see: https://github.com/zerocracy/judges-action/actions/runs/15468011763/job/43544725268

Let's try to refactor some hotspots, where the duplication is the most obvious.

[yegor256]

@Yegorov take a look, please. You can study the log, find out where are the hotspots, and report bugs about them. Then, fix them. Or, you can simply submit pull requests with the fixes, if they are obvious.

[Yegorov]

@yegor256 What kind of duplication are we talking about: where there are many requests for one URL? Or where there are many single requests?

Follow logs, for example (👉 Running assignee-was-attached (#1) at judges/assignee-was-attached/ (12s already)...):

  https://api.github.com/repositories/798641472: 84
  https://api.github.com/repositories/799113787: 81
  https://api.github.com/repositories/799177290: 61
  https://api.github.com/repositories/802720676: 58
  https://api.github.com/repositories/820463873: 40
  https://api.github.com/repositories/181044958: 21
  https://api.github.com/repositories/840215648: 7
  https://api.github.com/repositories/974194993: 2

84 times Fbe.octo.repo_name_by_id(798641472) called https://api.github.com/repositories/798641472
In this case, caching should work, for example:

#!/usr/bin/env ruby
# frozen_string_literal: true

require 'bundler/setup'
require 'loog'
require 'judges/options'

require 'fbe/octo'

$global = {}
$options = Judges::Options.new()
$loog = Loog::VERBOSE

octo = Fbe.octo(options: $options, global: $global, loog: $loog)
$loog.info("remaining: #{octo.rate_limit.remaining}")
octo.print_trace!
10.times do
  r = octo.repo_name_by_id(798641472)
end
octo.print_trace!
$loog.info("remaining: #{octo.rate_limit.remaining}")
binding.irb

and output log:

D: The 'github_token' option is not provided
D: The 'GITHUB_TOKEN' environment variable is not set
Accessing GitHub API without a token!
D: Octokit::Client.rate_limit() in 388ms
remaining: 59
GitHub API trace (1 URLs vs 1 requests):
  https://api.github.com/rate_limit: 1
D: Octokit::Client.repository(798641472) in 385ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
D: Octokit::Client.repository(798641472) in 1ms
D: GitHub repository #798641472 has a name: yegor256/factbase
GitHub API trace (1 URLs vs 10 requests):
  https://api.github.com/repositories/798641472: 10
D: Octokit::Client.rate_limit() in 14μs
remaining: 58 #<--------------------------------------------- was 59 in start, we only made one request

For this case (many single requests):

  https://api.github.com/repos/yegor256/factbase/issues/53/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/54/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/55/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/57/events: 1
  https://api.github.com/repos/yegor256/judges/issues/1/events: 1
  https://api.github.com/repos/yegor256/judges/issues/3/events: 1
  https://api.github.com/repos/yegor256/judges/issues/4/events: 1
  https://api.github.com/repos/yegor256/judges/issues/5/events: 1
  https://api.github.com/repos/yegor256/judges/issues/6/events: 1
  https://api.github.com/repos/yegor256/judges/issues/7/events: 1
  https://api.github.com/repos/yegor256/judges/issues/8/events: 1
  https://api.github.com/repos/yegor256/judges/issues/9/events: 1
  https://api.github.com/repos/yegor256/judges/issues/10/events: 1
  https://api.github.com/repos/yegor256/judges/issues/11/events: 1
  https://api.github.com/repos/yegor256/judges/issues/12/events: 1
  https://api.github.com/repos/yegor256/judges/issues/13/events: 1
  https://api.github.com/repos/yegor256/judges/issues/14/events: 1
  https://api.github.com/repos/yegor256/judges/issues/15/events: 1
  https://api.github.com/repos/yegor256/judges/issues/16/events: 1
  https://api.github.com/repos/yegor256/judges/issues/17/events: 1
  https://api.github.com/repos/yegor256/0rsk/issues/36/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/27/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/28/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/29/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/30/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/32/events: 1
  https://api.github.com/repos/yegor256/factbase/issues/33/events: 1

It's probably better to add an attribute check_assigned_after to issue-was-opened fact and randomly fill it for viewed facts from 24 to 48 hours from now.
What do you think?

[yegor256]

@Yegorov of course, we should expect caching middleware (in Fbe.octo) to help. We should try to reduce the amount of first requests to GitHub. At the same time, let's try to avoid factbase polution with supplementary properties. We should keep there only the information related to actual data, not our meta data that solves our technical problems.