Series: Building DevDocAI — A Production Multi-Agent LangGraph System

Part 5 — Backend Closed Out, GitHub OAuth Working End-to-End

Quick Update

Short post this time — but a meaningful checkpoint.

Since Part 4, two things happened:

1. The backend is now fully complete — all 13 endpoints, tested and working.
2. GitHub OAuth is wired frontend → backend → GitHub → back again, and I watched it work end-to-end for the first time.

That second one felt bigger than it sounds. Let me walk through both.

Backend — The Final Two Endpoints

Part 4 left two gaps: no way to browse a user's actual GitHub repos, and no way to trigger the pipeline outside of a PR merge webhook. Both are closed now.

GET /github/repos
Pulls the user's repos directly from GitHub — not from our DB. New MCP tool, list_user_repos, wraps PyGithub's user.get_repos() and returns the fields the frontend actually needs: name, default branch, visibility, language.

POST /repos/{repo_id}/run
The manual trigger. Connect a repo → hit this → the full LangGraph pipeline starts immediately instead of waiting for a PR to merge. Same run_pipeline() the webhook uses, just a different entry point and trigger="manual" instead of "pr_merge".

Full endpoint list now:

POST  /auth/register
POST  /auth/login
GET   /auth/github
POST  /auth/github/callback
GET   /auth/me
POST  /webhooks/github
GET   /repos
GET   /github/repos
POST  /repos/connect
POST  /repos/{repo_id}/run
GET   /pipeline/{thread_id}/state
POST  /pipeline/review
POST  /chat/ask

Backend's done. Every agent, every checkpoint, every route the frontend needs — all there.

GitHub OAuth — Where It Actually Broke

This is the part worth writing down, because the bug was sneaky.

The flow is: frontend asks the backend for a GitHub authorize URL, backend builds it using GITHUB_REDIRECT_URI from .env, GitHub redirects back to that exact URI with a code, frontend catches it and exchanges it for a session.

I updated GITHUB_REDIRECT_URI in .env from the backend's own callback route to the frontend's:

# before
GITHUB_REDIRECT_URI=http://localhost:8000/auth/github/callback

# after
GITHUB_REDIRECT_URI=http://localhost:3000/auth/callback

Updated the GitHub OAuth App's redirect URI to match. Tested without restarting the server. GitHub threw:

Be careful! The redirect_uri is not associated with this application.

The URL in the browser still showed localhost:8000. .env was correct. GitHub App settings were correct. So why was the old value still being used?

@lru_cache() on get_settings(). The settings object gets built once and cached for the life of the process — editing .env while the server is still running (even with --reload, which only watches code files, not env vars) does nothing. A full stop and restart was needed to actually rebuild the cached Settings instance.

Small gotcha, easy fix, but worth remembering: env var changes need a hard restart, not a hot reload.

Seeing It Work

After the restart, the full loop:

/login → "Continue with GitHub"
      → GitHub authorize screen
      → redirects to localhost:3000/auth/callback?code=xxx
      → frontend exchanges code with backend
      → JWT stored
      → /dashboard

And it just worked. Landed on the dashboard, GitHub username in the top corner, no errors in either console.

There's something different about a full auth loop working versus a single endpoint returning 200 in Swagger. This is the first time a real browser, a real GitHub account, and the actual frontend all talked to each other correctly. It's the first "this feels like a product" moment in the project.

Where Things Stand

The dashboard is currently rendering against sample repos. Next step is swapping that for GET /repos and GET /github/repos, and making "Connect repository" actually call POST /repos/connect followed by POST /repos/{id}/run.

That's Part 6.

GitHub

START
  ↓
codebase_parser

Building in public — one working loop at a time.

Tags: python nextjs oauth fastapi langgraph webdev opensource