chrisns / repomanager / 27027258438

86%

push

github

Cut Lambda cost: stop the cron worker burning GB-seconds

The May bill tripled (870k -> 2.56M GB-s, $6.56 -> $28.85), all of it
cron-worker compute. CloudWatch showed the worker at 208s avg / 360s max
with a 54% error rate: ~2 large installations time out at 360s every
10-minute tick and, with no async-retry cap, were billed 3x.

Compounding causes, all fixed here:

- template.yaml: the worker had no EventInvokeConfig, so AWS retried every
  timed-out invoke twice (3x billing). Set MaximumRetryAttempts: 0 — a cron
  worker has no value being retried, the next tick is the retry. Drop the
  inherited 360s Timeout to 240s to bound a wedged tenant, and move the cron
  from rate(10 minutes) to rate(1 hour): webhooks already apply config
  changes in real time, so the cron is only a safety-net reconcile.

- handler.js: process an installation's repos with bounded concurrency
  (WORKER_CONCURRENCY, default 6) instead of strictly serially, so a large
  tenant finishes inside the timeout instead of starving its tail. Also
  short-circuit the bot's own issues.edited deliveries before createApp/HMAC
  verify — GitHub re-delivers every consent-issue edit we make and each was a
  billed invocation we discarded anyway.

- src/consent.js: skip the throttled search API on the no-drift path. octokit
  serialises search to ~2s/call and we hit it for every repo every tick; the
  listForRepo union already finds the issue to close.

- src/planner.js: diff security-and-analysis flags against actual state
  instead of re-applying all six every tick. Skips already-enabled flags and
  features GitHub doesn't offer (killing the perpetual "failed to apply
  secretScanning: not available" loop), reusing a single repos.get.

- src/octokit.js: bound the throttle handlers so a worker is never billed to
  sleep 60s on a secondary rate limit; fail fast and let the next tick retry.

Projected steady-state usage drops well under the 400k GB-s/month free tier.

403 of 520 branches covered (77.5%)

Branch coverage included in aggregate %.

49 of 54 new or added lines in 3 files covered. (90.74%)

668 of 730 relevant lines covered (91.51%)

20.75 hits per line