chaidocs
git-wiki

core-archtecture

Suraj Kumar Jha 5 pages 2 min read Updated Sep 11, 2026
On this page
  1. Why Async: Instant Receipts, Slow Cooking
  2. Step Checkpoints: Never Start Over
  3. Write Path: Indexing Repository Code
  4. Read Path: RAG Similarity Search
  5. Two Paths, One Vector Namespace

Why Async: Instant Receipts, Slow Cooking

01 On the far left, a user device box sends a 'POST /api/index' arrow to an Express API box. Express splits the action into two arrows: a dotted arrow returns '200 OK + jobId #101' immediately back to the user, while a solid arrow sends 'repo/index.requested' to a large Inngest engine box on the right. Below the user box, a circular dotted loop labeled 'GET /jobId #101 (polling)' queries Express repeatedly.
Notes
When you order a pizza on Swiggy, the app gives you an Order ID in 50 milliseconds instead of freezing your screen for 25 minutes while the kitchen bakes it. Similarly, an Express server will timeout if an HTTP request stays open for 2 minutes while downloading, splitting, and embedding a GitHub codebase. Calling `POST /api/index` creates a job marked 'queued', fires a background event to Inngest, and returns a `jobId` immediately. The client browser polls `GET /:jobId` every 2 seconds to check if status flipped from 'running' to 'completed'.

Step Checkpoints: Never Start Over

02 A vertical stack of three rounded step boxes inside an Inngest container. Box 1 'fetch-github-files' has a green checkmark, Box 2 'chunk-files' has a green checkmark, and Box 3 'save-to-pinecone' displays an orange warning triangle. A curved retry arrow loops directly from an Inngest scheduler node outside the container into Box 3, completely bypassing Box 1 and Box 2.
Notes
If an IRCTC Tatkal payment fails after seat allocation, you want the app to retry only the UPI payment, not restart coach selection from zero. Inngest wraps every heavy operation inside `step.run()`, checkpointing intermediate outputs to durable storage. If GitHub file download succeeds but Pinecone vector upsert fails due to a network glitch, Inngest retries ONLY the Pinecone step. This prevents wasted OpenAI API billing and stops your app from exhausting GitHub's 5,000 requests-per-hour rate limit.

Write Path: Indexing Repository Code

03 A horizontal 4-stage pipeline flowing left to right. Node 1 shows a GitHub Octocat icon outputting '200 raw files', pointing to Node 2 'LangChain Splitter' producing '1000-char chunks (150 overlap)'. An arrow connects Node 2 to Node 3 'OpenAI Embeddings' generating vector arrays, which point into Node 4 'Pinecone Vector DB' labeled with namespace tag 'owner-repo'.
Notes
Triggered by `repo/index.requested`, Step 1 fetches up to 200 source files from GitHub's tree API. Step 2 runs locally on the CPU, splitting files into 1,000-character LangChain text chunks with a 150-character overlap to preserve syntax boundaries. Step 3 sends chunks to OpenAI `text-embedding-3-small` and upserts vectors into Pinecone under an isolated namespace formatted as `owner-repo`. Once vectors are written, the job marks itself 'completed' and records final metrics like 140 files and 520 chunks.

Read Path: RAG Similarity Search

04 A central box labeled 'ask-question (Inngest)'. On its left, an arrow sends an embedded query vector into a cylinder labeled 'Pinecone: owner-repo', which returns an arrow with 'Top 5 Chunks (k=5)'. These 5 chunks feed into a 'GPT-4o-mini' box on the right, which outputs two distinct arrows labeled 'Markdown Answer' and 'Source File List' into a completed job store box at the bottom.
Notes
When a developer submits a question via `POST /api/chat`, Express responds with HTTP 202 and delegates work to `ask-question`. This function never touches GitHub; it embeds the user query and asks Pinecone for the top 5 (k=5) closest vector chunks inside that repo's namespace. It injects those 5 code chunks into a strict system prompt: 'Answer using this repo context only' to eliminate AI hallucinations. GPT-4o-mini generates the response within 2 to 4 seconds, returning both the Markdown answer and the specific source file paths.

Two Paths, One Vector Namespace

05 Two parallel horizontal tracks converging on a central cylinder labeled 'Pinecone Namespace: owner-repo'. The top track shows 'Write Path: index-repo' with a downward green write arrow pushing 500 vector chunks into the cylinder. The bottom track shows 'Read Path: ask-question' with a bidirectional blue query arrow reading 5 chunks from the cylinder. A red 'No Direct Call' line separates the two worker tracks.
Notes
The write path (`index-repo`) runs once per repository commit, converting hundreds of source files into searchable vectors. The read path (`ask-question`) runs hundreds of times as teammates ask multiple questions about the codebase. Neither function directly invokes the other; their only shared touchpoint is the isolated Pinecone namespace `owner-repo`. If a user queries a repository before indexing completes, Pinecone returns 0 vectors and the LLM safely reports empty context.