DEV Community: Eshaan Agrawal

The Cache Was Working. And Still Causing Duplicate API Calls

Eshaan Agrawal — Fri, 03 Jul 2026 07:50:03 +0000

The Cache Was Working. And Still Causing Duplicate API Calls.

The cache wasn't broken.
Every response was being stored correctly.
Every cache hit was returning instantly.

And yet — three concurrent requests for the same username were hitting GitHub three times.

This is the story of a thundering herd bug I found in CommitPulse — a high-performance Next.js API that transforms raw GitHub contribution data into 3D isometric SVG streak badges. 106 stars, actively used, real traffic hitting the GitHub API on every badge render and dashboard load.

The cache worked perfectly for sequential requests. Concurrent ones were a different story.

What is CommitPulse

Quick context before the bug.

CommitPulse takes a GitHub username, fetches contribution data from GitHub's GraphQL API, and renders it as a premium SVG badge. The kind you embed in a README. Every time someone loads a page with your badge, a request fires. If your README gets popular, that's a lot of requests — and GitHub's API has rate limits.

So CommitPulse has a cache layer. Fetch once, store the result, return it for subsequent requests. Makes sense. The problem was what happened before the first response came back.

How I Found It

I was reading through lib/github.ts tracing the contribution fetch path end-to-end.

The cache check looked like this — simplified, but this is the pattern across contribution, profile, and repo fetches:

// lib/github.ts:254-258
const cached = await contributionsCache.get(key)
if (cached) return cached

const res = await fetchWithRetry(GITHUB_GRAPHQL_URL, options)
// ... process response
contributionsCache.set(key, result)
return result

Check cache. Miss. Fetch from GitHub. Store result. Return.

That's correct for a single request. But read it again thinking about two requests arriving at the same time for the same username.

Request A arrives. Checks cache. Miss. Starts fetching from GitHub.

Request B arrives 5ms later. Checks cache. Miss — because Request A hasn't finished yet, so nothing is stored. Starts fetching from GitHub.

Request C arrives 10ms later. Same thing. Third GitHub API call for identical data.

All three requests check the cache, all three see a miss, all three independently hit GitHub. The first one to finish populates the cache. But by then, the other two have already sent their requests.

The cache only helps after a response is complete. While the first request is still in-flight, every concurrent request for the same key goes straight to GitHub.

Why This Actually Matters

For a badge that's embedded in one README and gets 50 views a day, this is invisible. Fine.

But CommitPulse serves public badges. A popular README can get thousands of views in a short burst — a Hacker News post, a GitHub trending spike, a deploy cold start where the cache is empty. In those moments, concurrent requests for the same username fire simultaneously, and without in-flight deduplication, every one of them hits GitHub independently.

GitHub's GraphQL API has rate limits. Authenticated requests get 5,000 points per hour. A complex contribution query costs points. During a cold start with high traffic, this amplifies GitHub API usage proportionally to the number of concurrent requests — not proportionally to the number of unique usernames.

This is the thundering herd problem. A cache miss under load triggers a flood of identical upstream calls, each one racing to populate the cache with the same data.

The Fix: In-Flight Request Deduplication

The solution is to track pending requests separately from completed cache entries.

When a cold miss happens and a fetch starts, store the pending Promise in a Map keyed the same way as the cache. Any concurrent request that misses the cache checks the in-flight map next — if there's already a pending request for that key, return the same Promise instead of starting a new one.

Once the request settles (success or failure), remove it from the in-flight map.

Here's the implementation for the contributions fetch path:

// lib/github.ts — after PR #1589

// in-flight request maps, one per data type
const contributionsInFlight = new Map<string, Promise<GitHubContributions>>()
const profileInFlight = new Map<string, Promise<GitHubProfile>>()
const reposInFlight = new Map<string, Promise<GitHubRepo[]>>()

async function fetchGitHubContributions(
  username: string,
  year: number,
  bypassCache = false
): Promise<GitHubContributions> {
  const key = `${username}:${year}`

  // 1. check completed cache first
  if (!bypassCache) {
    const cached = await contributionsCache.get(key)
    if (cached) return cached
  }

  // 2. check in-flight map — return existing promise if one is pending
  if (!bypassCache && contributionsInFlight.has(key)) {
    return contributionsInFlight.get(key)!
  }

  // 3. cold miss — start the fetch, register it in the in-flight map
  const request = fetchWithRetry(GITHUB_GRAPHQL_URL, options)
    .then(async (res) => {
      const result = await processResponse(res)
      contributionsCache.set(key, result)
      return result
    })
    .finally(() => {
      contributionsInFlight.delete(key)  // clean up after settling
    })

  contributionsInFlight.set(key, request)
  return request
}

Three things happening here:

First, check the completed cache (unchanged from before). Second, check the in-flight map — if a request is already pending for this key, return that same Promise. All concurrent callers now share one pending request. Third, on a genuine cold miss, create the fetch Promise, register it in the in-flight map, and remove it in finally once it settles.

The bypassCache / refresh=true path intentionally skips both the cache and the in-flight map. An explicit refresh should always be a real fresh request — that's the whole point of a force refresh.

The Repro Test

The clearest way to verify this class of bug is to delay the mock fetch slightly and fire concurrent requests:

// before the fix — this test would fail (fetch called 3 times)
it('deduplicates concurrent cold cache misses', async () => {
  let fetchCount = 0

  vi.mocked(fetch).mockImplementation(async () => {
    fetchCount++
    await new Promise(r => setTimeout(r, 50))  // simulate network delay
    return mockGraphQLResponse()
  })

  // fire three concurrent requests for the same username
  await Promise.all([
    fetchGitHubContributions('octocat', 2026),
    fetchGitHubContributions('octocat', 2026),
    fetchGitHubContributions('octocat', 2026),
  ])

  // should only have hit GitHub once
  expect(fetchCount).toBe(1)
})

Without deduplication: fetchCount is 3. All three concurrent requests miss the cache before any of them finish.

With deduplication: fetchCount is 1. Requests B and C see the pending Promise from Request A and return it directly. GitHub gets one call.

I added this regression test for all three data paths — contributions, profile, and repos — so the behavior is pinned going forward.

The Broader Pattern

This is a specific instance of a pattern called request coalescing — combining multiple identical pending requests into one.

It comes up whenever you have:

A cache that only holds completed responses
High concurrency or bursty traffic
An upstream resource with rate limits or cost (GitHub API, a database, a paid third-party service)

The cache alone isn't enough. You need deduplication at the in-flight level too.

The in-flight Map approach is the standard fix. It's small — a Map per data type, a few lines of check-and-register logic — and it slots cleanly into existing cache code without changing the API surface or the completed-cache behavior.

If you're building anything with a cache layer that sits in front of a rate-limited API — check whether your in-flight requests are deduplicated. If they're not, a cold start under load will hit your upstream harder than you expect.

While I Was There — Three More Bugs

Since I was deep in lib/github.ts already, I kept reading. Found three more things worth fixing in the same file:

PR #855 — getHeaders() always built an Authorization: bearer ${process.env.GITHUB_PAT || process.env.GITHUB_TOKEN} header. When neither variable was set, outgoing requests got Authorization: bearer undefined. Not a valid credential, and the only feedback was a confusing 401 from GitHub. Fixed it to resolve the token first, validate it, and throw a clear config error before making any request.

PR #1131 — fetchWithRetry added an abort event listener to the caller's AbortSignal on every attempt but never removed it after the request settled. On successful requests, retries, and network failures, stale listener references accumulated on long-lived signals. Fixed it with a named callback and a finally cleanup.

PR #1244 — GitHub REST helpers were inserting raw usernames directly into URL paths: `/users/${username}`. A username containing /, ?, or # reshapes the URL instead of being treated as one path segment. Fixed it with encodeURIComponent(username) before building REST URLs, with regression tests asserting / becomes %2F.

Four bugs. One file. Same pattern across all of them — code that works fine for the normal happy path but quietly misbehaves under edge cases or load.

I Found 4 Bugs in an AI Student Platform — Here's What Was Actually Wrong

Eshaan Agrawal — Wed, 01 Jul 2026 16:18:35 +0000

A GET endpoint inserting rows into a production database.
A notification bell hammering an API with requests before the user even signed in.
Failed API calls silently showing up as empty states.
A frontend component expecting { doubts, pagination } from an API that returned a plain array.

Four separate bugs. One codebase. All found in the same sitting.

This is a writeup of everything I found and fixed in DoubtDesk — an anonymous, AI-powered doubt-solving platform built for students to ask questions without fear and get instant answers. TypeScript, Next.js, Clerk auth, and a Postgres database on the backend.

I'm writing this because every one of these bugs is something you will build yourself at some point. Not because you're a bad developer — because they're easy to miss and nobody teaches you to look for them.

The one that actually surprised me

I'll start with the worst one. Not the most complex. Just the one that made me go back and re-read the code twice because I thought I was misreading it.

src/app/api/notifications/test-seed/route.ts

// the exported handler
export async function GET(request: Request) {
  const { userId } = auth()

  // ...

  await db.insert(notificationsTable).values(dummyNotifications)

  return NextResponse.json({ success: true })
}

A GET handler. Doing a database insert.

GET /api/notifications/test-seed — a standard HTTP GET request — was inserting dummy notification rows for whatever signed-in user hit the endpoint. No NODE_ENV check. No dev-only gate. Live in normal app builds, accessible in production.

What that means in practice:

Open the URL in a browser — inserts data
Refresh the page — inserts more data
A crawler or bot visits the URL — inserts data
Someone shares the link — inserts data for everyone who clicks it

Every visit created new notification rows. No confirmation. No intent. Just visiting a URL.

And when it failed, the catch block returned this:

return NextResponse.json({
  error: "Seeding failed",
  details: error.message,
  stack: error.stack  // full stack trace to the client
})

Stack traces in API responses. In a production endpoint.

Why this happens

Test helpers get written fast. Someone needs dummy data for local development, writes a quick seed route, ships it, and moves on. The app works. Nobody notices the route is still live because in development it's harmless — you're the only one hitting it and the data doesn't matter.

The gap is that test helpers need the same production discipline as real routes:

gate them behind NODE_ENV === "development" or remove them entirely
never expose mutation via GET — GET should be read-only by HTTP convention
never return error.stack to the client

The fix was straightforward. Block the route in production, switch mutation to POST, strip the stack trace from the error response:

// after — PR #451
export async function GET() {
  return NextResponse.json(
    { error: "Method not allowed" },
    { status: 405 }
  )
}

export async function POST(request: Request) {
  if (process.env.NODE_ENV === "production") {
    return NextResponse.json({ error: "Not found" }, { status: 404 })
  }

  // seeding logic only runs in dev/test
  await db.insert(notificationsTable).values(dummyNotifications)
  return NextResponse.json({ success: true })
}

GET returns 405. POST is the only mutation path. Production returns 404. Error responses return a generic message — no stack, no details.

I also added Jest coverage for the blocked GET, the successful POST seed, and the production gate. Because a security fix without a test is just a comment promising it won't happen again.

The notification bell polling before auth

While fixing the seed route I was already in the notification code, so I opened src/components/NotificationBell.tsx.

Line 31:

const { data, error } = useSWR('/api/notifications', fetcher, {
  refreshInterval: 10000
})

Unconditional. No auth check. No isLoaded guard.

The notification bell starts polling /api/notifications every 10 seconds from the moment the component renders — before Clerk has confirmed whether the user is signed in, during sign-in, after sign-out, after persistent API failures. It just keeps going.

Open the network tab and you'd see a stream of requests hitting the notifications endpoint from the second the page loads, regardless of auth state. Each one returning a 401 for a signed-out user. Each one triggering an automatic SWR retry. Repeated 401s, noisy server logs, wasted work — all for a header widget that can't show useful data in that state anyway.

The fix is gating the SWR key on Clerk auth state. SWR treats a null key as "don't fetch" — so you pass null when the user isn't loaded or isn't signed in, and the real URL only when auth is confirmed:

// before
const { data, error } = useSWR('/api/notifications', fetcher, {
  refreshInterval: 10000
})

// after — PR #442
const { isLoaded, isSignedIn } = useAuth()

const { data, error } = useSWR(
  isLoaded && isSignedIn ? '/api/notifications' : null,
  fetcher,
  {
    refreshInterval: 10000,
    onErrorRetry: (error, _key, _config, revalidate, { retryCount }) => {
      if (retryCount >= 3) return  // stop retrying after 3 failures
      setTimeout(() => revalidate({ retryCount }), 5000)
    }
  }
)

Two changes: the SWR key is now conditional on isLoaded && isSignedIn, and repeated failures stop retrying after 3 attempts instead of hammering the API forever.

I also added a retry state — instead of showing an empty notification list when loading fails, the component now shows a "Try again" button. Because an empty list and a failed load are two completely different states and the user deserves to know which one they're looking at.

The bug that made failed requests look like empty data

Same theme, different components.

In src/app/bookmarks/page.tsx and src/components/RecommendedClassrooms.tsx, failed API requests were being silently swallowed:

// bookmarks/page.tsx — before
try {
  const res = await fetch('/api/bookmarks')
  const data = await res.json()
  setBookmarks(data)
} catch (err) {
  console.error(err)  // logged, not stored
  // falls through to empty state
}

If /api/bookmarks returned a 500, the catch block logged it and the component fell through to rendering "no bookmarks." Same for recommendations. A user staring at an empty bookmarks page had no way to know whether they had no bookmarks or the app had failed to load them.

Quick way to verify: temporarily return a 500 from either route. The UI shows "no bookmarks" like everything is fine.

The fix is checking res.ok before treating the response as valid data, and keeping an error state separate from empty data:

// after — PR #444
try {
  const res = await fetch('/api/bookmarks')
  if (!res.ok) {
    setError(`Failed to load bookmarks (${res.status})`)
    return
  }
  const data = await res.json()
  setBookmarks(data)
} catch (err) {
  setError('Something went wrong. Try again.')
}

Empty state only shows after a successful empty response. Failed responses show a clear message with a retry button. Two states, two different UIs. Simple.

The frontend-API contract mismatch

Last one. This one was pure API contract drift.

src/components/InfiniteDoubtFeed.tsx is a reusable infinite scroll component. It was written expecting each SWR page to look like this:

// what InfiniteDoubtFeed expected
{ doubts: Doubt[], pagination: { hasMore: boolean } }

But src/app/api/doubts/route.ts returned this:

// what the API actually returned
Doubt[]  // plain array

So page?.doubts was always undefined. The feed flattened to an empty list. Pagination never worked. The component had been built for a response shape the API never provided.

Nobody noticed because the component probably hadn't been wired into a live page yet — but it would have silently shown empty data the moment it was used.

// before — PR #443
const doubts = data?.pages.flatMap(page => page.doubts) ?? []
const hasMore = data?.pages.at(-1)?.pagination?.hasMore ?? false

// after — handles both shapes
const doubts = data?.pages.flatMap(page =>
  Array.isArray(page) ? page : (page.doubts ?? [])
) ?? []

const hasMore = data?.pages.at(-1) !== undefined
  ? Array.isArray(data.pages.at(-1))
    ? (data.pages.at(-1) as Doubt[]).length > 0
    : (data.pages.at(-1) as { pagination: { hasMore: boolean } })
        .pagination?.hasMore ?? false
  : false

The component now handles both the current plain array response and the object shape with pagination — so it works today and keeps working if the API changes later. I also made the local fetcher throw on non-2xx responses so failed loads don't get treated as valid page data.

The pattern across all four bugs

These are different bugs but they share the same root cause: things that work in development silently failing in production — or worse, silently misbehaving without failing at all.

The test seed route worked fine locally because the developer was the only one hitting it. The notification polling worked fine in a signed-in session because that's the only state it was tested in. The empty state bug was invisible until you deliberately broke the API. The contract mismatch was invisible until you wired the component to a real page.

The fix for all of them is the same mindset: test failure cases, not just happy paths. What happens when the user is signed out? What happens when the API returns a 500? What happens when the response shape doesn't match what the component expects?

If you're building a Next.js app right now — open your network tab, sign out, and watch what requests fire. You'll probably find something.

The Bug That Sends "Authorization: bearer undefined" - And Why It's So Easy to Miss

Eshaan Agrawal — Tue, 30 Jun 2026 22:33:41 +0000

`Authorization: bearer undefined`

No error. No stack trace. Just a 401 that looked like it came from nowhere.

I was poking around CommitPulse locally — it's the open-source project that generates those GitHub streak/contribution SVGs you see embedded in people's READMEs. I hadn't set a token in my .env yet. Figured I'd see what broke.

What broke was confusing in a specific way: it didn't fail at startup, it didn't fail with a config error, it just quietly sent a bad request to GitHub's GraphQL API and let GitHub be the one to reject it.

Tracing it back

I went looking for where the GitHub client builds its request headers. Found it in lib/github.ts:

// lib/github.ts:185-187 — before
const getHeaders = () => ({
  Authorization: `bearer ${process.env.GITHUB_PAT || process.env.GITHUB_TOKEN}`,
  'Content-Type': 'application/json',
});

That's it. That's the whole bug.

If neither GITHUB_PAT nor GITHUB_TOKEN is set, process.env.GITHUB_PAT || process.env.GITHUB_TOKEN evaluates to undefined. Template literals don't care. They'll happily stringify that into the header anyway:

Authorization: bearer undefined

That's a syntactically valid HTTP header. GitHub's API has no way to know "undefined" isn't a real token — it just sees garbage credentials and responds with a 401, same as it would for any other malformed token.

Why this one's easy to miss

The failure mode looks exactly like an upstream GitHub problem. You get a 401, you check your token, you check your scopes, maybe you regenerate the PAT — none of that helps, because the actual bug is three layers upstream of the request that's failing.

It also doesn't fail in CI or in prod, where the env var is almost always set. It only shows up for a contributor cloning the repo fresh and trying to run it locally without realizing a token is required. So the people most likely to hit it are exactly the people least equipped to debug it — first-time contributors, during setup, before they have any context on the codebase.

The fix

Resolve the token once, validate it's actually there, and fail loudly before the request goes out:

// lib/github.ts — after
const MISSING_GITHUB_TOKEN_MESSAGE = 'GitHub token is missing. Set GITHUB_PAT or GITHUB_TOKEN.';

function getGitHubToken(): string {
  const token = process.env.GITHUB_PAT || process.env.GITHUB_TOKEN;
  if (!token || token.trim() === '') {
    throw new Error(MISSING_GITHUB_TOKEN_MESSAGE);
  }
  return token;
}

const getHeaders = () => ({
  Authorization: `bearer ${getGitHubToken()}`,
  'Content-Type': 'application/json',
});

Same fallback behavior — GITHUB_PAT first, GITHUB_TOKEN second — but now a missing token throws a clear Error before fetchWithRetry ever gets called. No network round trip. No GitHub 401 to misread. Just an immediate, readable message pointing at the actual problem.

The tests cover all three cases now: GITHUB_PAT present, falling back to GITHUB_TOKEN, and neither set:

it('throws before fetching when no GitHub token is configured', async () => {
  delete process.env.GITHUB_PAT;
  delete process.env.GITHUB_TOKEN;

  await expect(fetchGitHubContributions('octocat')).rejects.toThrow(
    'GitHub token is missing. Set GITHUB_PAT or GITHUB_TOKEN.'
  );
  expect(fetch).not.toHaveBeenCalled();
});

That last assertion matters as much as the error message — it confirms the fetch never even fires once the token's missing, instead of trusting GitHub to reject it correctly.

What I'd flag for next time

Any place a template literal builds an auth header from an env var deserves a second look. ${process.env.X} will never throw — it'll just smile and hand you the string "undefined". If the thing on the other end of that header is permissive enough to accept a malformed credential and reject it later, your error shows up in the wrong place, attributed to the wrong cause.

If you're tracing a new codebase and you find a request that authenticates with an environment variable — check what happens when that variable isn't set. Don't assume it throws. Go read it. You might find your first PR sitting right there.

How I Found a Silent API Bug in a 3,548-Star MCP Server

Eshaan Agrawal — Mon, 29 Jun 2026 05:44:47 +0000

How I Found a Silent API Bug in a 3,548-Star MCP Server

The API accepted your request. Returned HTTP 200. And then quietly did nothing.

No error. No stack trace. Just an empty result where your Cypher query should have run.

This is the story of how I found that bug in CodeGraphContext — an MCP server that indexes local codebases into a graph database to give AI assistants real code context. 3,548 stars. Actively maintained. Used by developers building on top of Claude and other LLM toolchains.

And it had a silent failure sitting in its public HTTP query endpoint.

What is CodeGraphContext?

Before the bug — quick context.

CodeGraphContext is an MCP (Model Context Protocol) server. It lets you point it at a codebase, index it into a graph database (FalkorDB or Kuzu), and then query that graph using Cypher — the query language for graph databases. The idea is that AI assistants can use it to understand code structure, dependencies, and relationships at a depth that flat file reads don't give you.

It exposes both an MCP interface and a standard HTTP API. The HTTP API is what's relevant here.

How I Found It

I wasn't hunting for bugs. I was reading the source.

When I contribute to a new repo, I start by tracing a single request end-to-end through the codebase. Pick an endpoint, follow it from the route definition into the handler, into any downstream calls, and back out. It's the fastest way to actually understand what a codebase does.

I started with /api/v1/query — the endpoint that lets you send a Cypher query over HTTP and get results back.

The route lives in src/codegraphcontext/api/router.py. Here's what I found at line 89:

server.handle_tool_call("execute_cypher_query", {
    "query": request.query,
    "params": request.params
})

The route was calling handle_tool_call with the tool name execute_cypher_query and passing the query as "query".

Then I went to the handler. src/codegraphcontext/tools/handlers/query_handlers.py, line 16:

cypher_query = args.get("cypher_query")
if not cypher_query:
    return {"error": "Cypher query cannot be empty."}

The handler reads cypher_query. Not query. cypher_query.

The route passes query. The handler reads cypher_query. They never meet.

So args.get("cypher_query") returns None. The handler hits the empty check. Returns {"error": "Cypher query cannot be empty."}. HTTP 200.

A valid request, carrying a real Cypher query, silently failed — not because the query was wrong, but because the key name didn't match across an internal function call boundary.

Why This Is Easy to Miss

The failure mode is the problem.

If this threw an exception, you'd see a 500. If it returned a 4xx, you'd know the API rejected your input. But it returned 200 with an error payload that looks like a validation error. The natural read is: "I sent a bad query." The actual problem is: the API layer and the tool handler were speaking different languages about what to call the same field.

Here's the repro from the issue I filed:

curl -X POST http://localhost:8000/api/v1/query \
  -H "Content-Type: application/json" \
  -d '{"query":"MATCH (n) RETURN count(n) AS count","params":{}}'

Valid Cypher. Valid JSON. Valid HTTP request. But the tool handler sees no cypher_query key — because the route called it query — and returns empty.

The request body looks correct at the API boundary. The failure happens after the internal translation. That's what makes it a confusing debugging path. You'd inspect the request, see a valid payload, and have no obvious reason to look at the key name being passed between the route and the handler.

The Fix

One line change in router.py:

# Before
server.handle_tool_call("execute_cypher_query", {
    "query": request.query,
    "params": request.params
})

# After
server.handle_tool_call("execute_cypher_query", {
    "cypher_query": request.query,
    "params": request.params
})

Change the key from "query" to "cypher_query" so it matches what the handler expects.

I kept the fix narrow — just aligning the key name, no refactoring, no schema changes. Then added a regression test in tests/unit/api/test_query_router.py that verifies a POST to /api/v1/query reaches execute_cypher_query with the correct key. So this can't silently break again.

What I Added: The Regression Test

This is the part I'd push anyone fixing a bug like this to do.

The fix itself is obvious once you see it. What's not obvious is that without a test, the exact same mismatch can come back — someone refactors the handler to read a different key, or the route gets updated without checking what the handler expects, and you're back to square one.

The test mocks server.handle_tool_call and asserts that after a valid POST to /api/v1/query, the mock is called with "cypher_query" in the arguments dict. Small test, precise assertion, catches exactly this class of regression.

def test_query_route_passes_cypher_query_key(client, mock_server):
    response = client.post(
        "/api/v1/query",
        json={"query": "MATCH (n) RETURN count(n)", "params": {}}
    )
    call_args = mock_server.handle_tool_call.call_args
    assert "cypher_query" in call_args[0][1]

The Broader Pattern

This is a specific instance of a bug pattern that shows up everywhere in layered systems: argument name drift.

You have a public interface (the HTTP route) that translates external input into an internal call. The public interface uses one name (query). The internal interface expects another (cypher_query). Both sides are internally consistent. The mismatch only exists at the translation boundary — and unless someone traces the full call path, it's invisible.

It's especially common when:

An internal tool or handler is defined separately from the route that calls it
The field names are semantically similar but not identical (query vs cypher_query)
The failure mode is a validation error rather than an exception (so it looks like bad input, not a broken translation)

The fix is always the same: trace the call, align the names, add a test that pins the contract.

What's Next

I also filed and opened PR #1026 on the same repo — the MCP SSE module was importing mcp.server and mcp.server.sse without declaring mcp as a runtime dependency in pyproject.toml. Clean installs could fail at import time with a ModuleNotFoundError on a code path the project advertises. That one's a writeup for another day.

If you're building on MCP or contributing to open source Python projects — read the source end-to-end before you start. One pass through a real request flow teaches you more about a codebase than reading the README three times.

This fix was part of my GSSoC 2026 contributions. I'm currently ranked #50 globally (S Tier, top 1% of 43,587 contributors) across 14 repos. Writing about the bugs that actually taught me something.

DEV Community: Eshaan Agrawal

The Cache Was Working. And Still Causing Duplicate API Calls

The Cache Was Working. And Still Causing Duplicate API Calls.

What is CommitPulse

How I Found It

Why This Actually Matters

The Fix: In-Flight Request Deduplication

The Repro Test

The Broader Pattern

While I Was There — Three More Bugs

Links

I Found 4 Bugs in an AI Student Platform — Here's What Was Actually Wrong

The one that actually surprised me

Why this happens

The notification bell polling before auth

The bug that made failed requests look like empty data

The frontend-API contract mismatch

The pattern across all four bugs

Links

The Bug That Sends "Authorization: bearer undefined" - And Why It's So Easy to Miss

`Authorization: bearer undefined`

Tracing it back

Why this one's easy to miss

The fix

What I'd flag for next time

How I Found a Silent API Bug in a 3,548-Star MCP Server

How I Found a Silent API Bug in a 3,548-Star MCP Server

What is CodeGraphContext?

How I Found It

Why This Is Easy to Miss

The Fix

What I Added: The Regression Test

The Broader Pattern

Links

What's Next