DEV Community: R.A. Olanrewaju

I built a serverless agent that finds open-source issues for me every morning

R.A. Olanrewaju — Mon, 22 Jun 2026 08:57:11 +0000

I contribute to OWASP Nest. Before that I was spending 20-30 minutes manually browsing GitHub for issues that matched my stack, most of which turned out to be stale, already claimed, or just not a good fit. I got tired of that. So I built something to do it for me.

The result is OSS-Contrib-Scout: a Lambda function that runs every morning at 8am, searches GitHub for Python issues tagged good-first-issue or help-wanted, scores each one against my actual stack using Gemini AI, and pushes a ranked digest to Telegram.

This post covers how it's built, what broke, and what a clean production run actually looks like.

The architecture

Three modules, one handler, one schedule.

EventBridge Scheduler (daily, 8am UTC)
        │
        ▼
   Lambda Function
        │
        ├── github_search.py   → GitHub Issues Search API
        ├── scorer.py          → Gemini API (scoring + filtering)
        └── notifier.py        → Telegram Bot API

github_search.py hits GitHub's Issues Search API with a query like is:open is:issue language:Python label:"good first issue", extracts the fields that matter (title, repo, body, labels, comment count), and returns a list.

scorer.py sends each issue plus a short profile of my stack to Gemini and asks for a JSON response: a score from 1-10 and a one-line reason. Anything below 6 gets dropped. The top 5 by score go to Telegram.

notifier.py formats the results as an HTML message and POSTs to the Telegram Bot API. I used HTML over Telegram's Markdown format because repo names often contain underscores that break Markdown parsing.

lambda_function.py is thin on purpose. It just calls the three functions in order and returns a status dict.

def lambda_handler(event, context):
    raw_issues = search_issues(language="Python", max_results=8)
    issues = [extract_issue_summary(i) for i in raw_issues]
    top_matches = score_and_filter(issues, min_score=6, max_results=5)
    send_digest(top_matches)
    return {"statusCode": 200, "issuesFound": len(issues), "issuesSent": len(top_matches)}

Infrastructure is defined in a SAM template: one Lambda function, one EventBridge schedule, one IAM execution role scoped to CloudWatch Logs only (the function makes outbound HTTPS calls to GitHub, Gemini, and Telegram, it doesn't need any AWS service permissions beyond logging).

Why Lambda and not EC2

This job runs for about 45 seconds, once a day. An EC2 instance would idle for 23 hours 59 minutes burning credits. Lambda charges only for actual execution time, and at this volume, the cost sits comfortably inside AWS's permanent free tier (1M requests/month, 400K GB-seconds/month). Not the trial credits, the always-free tier. The agent costs $0.00 to run.

I also have a trial AWS account with a finite credit budget. SAA-C03 labs need those credits more than a daily cron job does.

What broke

Three things broke, in order of how annoying they were to debug.

1. Gemini's free tier has a 20 requests/day cap on some accounts.

I knew the published number was around 1,500 requests/day for Flash-Lite. What I didn't know is that the actual limit varies by account, project, and billing state. The real number for my account turned out to be 20. I found this out by running the scorer against 15 issues back-to-back and watching every single one fail with a 429.

The error body told me everything:

"quotaId": "GenerateRequestsPerDayPerProjectPerModel-FreeTier",
"quotaValue": "20"

I'd built retry logic assuming these were per-minute rate limits, the kind you can wait out. But 20 per day means once you've hit the ceiling, waiting 5 seconds and retrying just wastes another request. I ripped the retry block out, dropped max_results from 15 to 8, and moved on. The lesson: check your actual quota from the API response body, not the docs.

2. python-dotenv crashed the Lambda function.

I use load_dotenv() locally to read .env files. Lambda doesn't use .env files, it reads environment variables from its own configuration. I'd deliberately excluded python-dotenv from the Lambda package to keep dependencies light. What I forgot to do was make the import conditional.

Runtime.ImportModuleError: Unable to import module 'lambda_function': No module named 'dotenv'

Fix was two lines:

try:
    from dotenv import load_dotenv
    load_dotenv()
except ImportError:
    pass

3. GitHub's API timed out twice.

Read timeout on the search call. Not a rate limit, not an auth issue, just a slow moment on GitHub's end. The fix was bumping the timeout from 10 seconds to 20 and adding a retry with backoff:

for attempt in range(3):
    try:
        response = requests.get(url, params=params, headers=headers, timeout=20)
        response.raise_for_status()
        return response.json().get("items", [])
    except requests.exceptions.RequestException as e:
        time.sleep(3 * (attempt + 1))
raise last_error

The first clean run

After the Gemini quota reset overnight, the agent ran on its EventBridge schedule for the first time without me touching anything.

CloudWatch logs:

08:00:25  INIT_START
08:00:26  Starting daily OSS contribution scan...
08:00:26  GitHub API rate limit remaining: 9
08:00:26  Found 8 candidate issues from GitHub
08:01:10  4 issues passed the scoring bar
08:01:10  Digest sent.
08:01:10  Duration: 44490ms  Billed: 44884ms  Memory: 63MB/256MB

45 seconds. 63MB peak memory. $0.00.

What landed in Telegram:

[8/10] Alerts: add email (SMTP), Slack and a generic webhook
repo: SikamikanikoBG/homelab-monitor
why: Backend focus on Python, API, and common integrations. Good fit.

[7/10] Improvements: Integration tests should be async
repo: langchain-ai/langchain-google
why: Backend focus, Python, and testing align well. Scope is clear.

[7/10] API keys shows two keys when only one is added
repo: RunestoneInteractive/rs
why: Backend bug in Python/Django with security implications.

[7/10] Add a Canada PIPEDA policy profile as a data-driven config
repo: maziyarpanahi/openmed
why: Good fit for backend, Python, and security interest.

The Django API key bug is the one I'll probably look at first. It's a backend bug with security implications, which is my exact lane, and the scope is clear enough to get into in an afternoon.

The scoring prompt

The most important thing in the whole system is PROFILE_CONTEXT, the block of text Gemini reads before scoring each issue. If this is wrong, the scores are useless.

Mine looks roughly like:

Backend developer, ~5 years experience.
Core stack: Python, Django, DRF, FastAPI, PostgreSQL, Redis, Docker.
Interested in: security-related issues (OWASP-adjacent), backend bugs,
API design issues, Django/FastAPI specifically.
NOT looking for: frontend-only issues, niche ML/data-science,
documentation-only unless very quick wins.

I also tell Gemini to score down issues with 10+ comments (likely already claimed) and issues with empty bodies (hard to act on without knowing what's actually wanted).

Deployment

It's a SAM template, so deployment is:

sam build
sam deploy --guided

First run asks for the stack name, region, and the three secrets (Gemini key, Telegram bot token, chat ID). Subsequent runs are just sam build && sam deploy. SAM creates the Lambda function, IAM role, and EventBridge rule as a single CloudFormation stack.

The repo is at github.com/Jpeg-create/OSS-Contrib-Scout if you want to run your own version. The PROFILE_CONTEXT in scorer.py is the main thing you'd change.

What's next

Two more agents are in progress using the same architecture: OSS-Solution-Drafter (on-demand fix drafting via DeepSeek when I decide to pursue an issue) and Job-Scout (daily job listing digest with tailored cover letter drafts). Both will get their own posts once they're running.

The code is straightforward. The interesting parts were the quota discovery and working out which retry logic actually helps versus which makes things worse. Building it taught me more about Lambda, EventBridge, and SAM than any course section covering the same topics, which was the point.

Building a Distributed Rate Limiter for FastAPI with Redis (Sliding Window Algorithm)

R.A. Olanrewaju — Sun, 08 Mar 2026 16:12:38 +0000

Building a Distributed Rate Limiter for FastAPI with Redis

Every API eventually runs into the same problem.

A bot, scraper, or even a buggy client suddenly starts sending thousands of requests per second. When that happens, your server slows down, your database struggles, and real users start seeing errors.

This is exactly the kind of situation rate limiting is meant to prevent.

Recently I built RateGuard, a small Python library that adds distributed rate limiting to FastAPI using Redis. In this post I want to walk through how it works and the design decisions behind it.

Why I Built RateGuard

While working with FastAPI, I looked at a few rate limiting libraries. Most of them had at least one issue.

Some only support in-memory limits, which means they break once your API runs on multiple servers.

Others work in distributed setups but require more infrastructure than I wanted.

So I decided to build something simple with a few goals in mind:

easy to plug into FastAPI
works across multiple servers
accurate under heavy traffic
simple enough to understand and maintain

That became RateGuard.

What Is Rate Limiting?

Rate limiting controls how many requests a user can send to an API within a certain time period.

For example:

a user can send 10 requests per minute
after the limit is reached they receive a 429 Too Many Requests response
after the time window passes the limit resets

A simple analogy is a coffee shop rule:

One free coffee per customer per hour.

The barista keeps track of who got a coffee and when. If you come back too soon, you have to wait.

Why Not Just Use a Counter?

A very common approach is to use a simple counter that resets every minute.

The problem is that this method can be abused.

Imagine your limit is 10 requests per minute and the counter resets at exactly 12:00:00.

A user could do this:

send 10 requests at 11:59:55
the counter resets at 12:00:00
send another 10 requests at 12:00:05

That ends up being 20 requests in about 10 seconds, even though the limit is supposed to be 10 per minute.

This issue is called the fixed window problem.

The Sliding Window Approach

To avoid this problem, RateGuard uses the sliding window algorithm.

Instead of resetting at fixed times, it always looks back a certain number of seconds from the current request.

The logic looks like this:

a request arrives at time T
check all requests between T - window and T
remove anything older than the window
count the remaining requests
if the count is below the limit, allow the request
otherwise return a 429 response

Going back to the coffee shop example, instead of resetting every hour on the clock, the barista asks:

Did this person get a coffee in the last 60 minutes?

The time window moves forward with every request.

Basic Architecture

RateGuard sits between incoming requests and your FastAPI application.

Client Request
      |
      v
FastAPI Server
      |
      v
RateGuard Middleware
      |
      v
Redis Sorted Set
      |
      v
Allow or Block Request

Redis stores request timestamps so every server in the system can see them.

Why Redis?

Redis is a good fit for rate limiting for two main reasons.

Speed

Rate limiting runs on every request, so it has to be fast. Redis is an in-memory data store and can handle a huge number of operations per second.

Shared state

If your API runs on several servers, each one needs to know how many requests have already been made. Redis works as a shared store that all servers can read from and write to.

Using Redis Sorted Sets

RateGuard stores request data inside a Redis Sorted Set.

A sorted set stores values with a score. The score determines the order.

In this case:

the score is the request timestamp
the value is a unique request ID

Example data:

Key: ratelimit:192.168.1.1

1709856060000 -> req_abc123
1709856080000 -> req_def456
1709856100000 -> req_xyz789

For each request, RateGuard:

removes entries older than the time window
counts the remaining entries
decides whether to allow or block the request
records the new request

This approach works well even when multiple servers are handling traffic.

Installing RateGuard

pip install rate-guardian

You will also need a Redis instance. I used Upstash Redis, which has a generous free tier.

Quick Example

import os
from fastapi import FastAPI, Request
from rateguard import RateGuard, RateLimitMiddleware, rate_limit

app = FastAPI()

limiter = RateGuard(
    redis_url=os.environ["UPSTASH_REDIS_REST_URL"],
    redis_token=os.environ["UPSTASH_REDIS_REST_TOKEN"],
)

app.add_middleware(
    RateLimitMiddleware,
    limiter=limiter,
    limit=10,
    window=60
)

@app.get("/")
async def home():
    return {"message": "API is protected by RateGuard"}

After adding the middleware, every endpoint is automatically protected.

Per Route Limits

Sometimes you want stricter limits for certain endpoints.

For example, a search endpoint that queries a database.

@app.get("/search")
@rate_limit(limiter, limit=5, window=60)
async def search(request: Request, q: str = ""):
    return {"query": q, "results": []}

Now /search only allows 5 requests per minute.

Response Headers

RateGuard includes useful headers in responses.

Header	Description
X-RateLimit-Limit	Maximum allowed requests
X-RateLimit-Remaining	Requests left
X-RateLimit-Reset	Seconds until reset
Retry-After	Only present on 429 responses

These help clients know when to slow down.

What Happens If Redis Fails?

One design decision I made was to fail open.

If Redis is temporarily unavailable, requests are allowed instead of blocked.

For most APIs, blocking all traffic because Redis is down would be worse than briefly running without rate limiting.

Core Logic Example

Here is a simplified version of the main logic:

import time
import uuid

def is_allowed(self, key: str, limit: int, window: int):
    now = int(time.time() * 1000)
    oldest = now - (window * 1000)

    pipe = self.redis.pipeline()
    pipe.zremrangebyscore(key, 0, oldest)
    pipe.zcard(key)
    pipe.zadd(key, {str(uuid.uuid4()): now})
    pipe.expire(key, window)

    results = pipe.exec()

    count = results[1]
    allowed = count < limit

    return allowed

Using a pipeline groups the Redis operations together and avoids race conditions.

What's Next

A few improvements I plan to add:

support for standard Redis deployments
rate limiting by user ID
an optional token bucket algorithm
better metrics and monitoring

Try It Out

pip install rate-guardian

GitHub: https://github.com/Jpeg-create/rate-guard

PyPI: https://pypi.org/project/rate-guardian/

If you find it useful, a ⭐ on GitHub means a lot.