DEV Community: Daniel Akudbilla

Worth Reading

Daniel Akudbilla — Mon, 20 Jul 2026 19:07:46 +0000

Daniel Akudbilla

Jul 20

Killing N+1 Queries: From Per-Row Lookups to Flat, Batched Reads

#performance #database #backend #sql

8 min read

Killing N+1 Queries: From Per-Row Lookups to Flat, Batched Reads

Daniel Akudbilla — Mon, 20 Jul 2026 19:06:46 +0000

You ship a read endpoint. It lists some things, say devices or orders or invoices, and for each row it pulls in a bit of related data. With five rows in the demo it's instant. Six months and a few thousand rows later, the same endpoint takes seconds and sits at the top of your slow-query dashboard.

Usually the culprit isn't a slow query. It's a fast query run thousands of times. That's the N+1 problem. I recently fixed two different versions of it in the same codebase, so this post walks through both, plus the fix, plus a test that stops it coming back.

The examples use a made-up domain: a dashboard listing active devices, where each row needs the device's site, that site's latest billing window, a premium-plan flag, and an install date. The domain doesn't matter. The shapes do.

What N+1 means

You run 1 query to fetch a list of N items, then N more queries (one per item) for the related data. One plus N.

// 1 query: get the list
val devices = deviceRepo.findActive()

val rows = devices.map { device ->
    // N queries: one lookup per device, inside the loop
    val site   = siteRepo.findById(device.siteId)
    val window = billingRepo.latestWindow(device.siteId)
    val date   = assetRepo.installDate(device.serialNumber)
    Row(device, site, window, date)
}

Three lookups per device and 1,000 devices is 3,001 queries to render one page. Each query is tiny. But each one pays for a network round-trip, connection checkout, planning, and result marshalling, and they run sequentially: query 2 waits for query 1 to come back. So latency ends up dominated by the number of round-trips rather than the work inside any single one. This is why the code feels fine in a test against localhost and falls over against a database one network hop away.

What makes it hard to catch in review is that nothing looks wrong. Every line is a reasonable single-row fetch. The problem only becomes visible once you notice where the loop is.

Shape 1: the assembly loop

The example above is the classic form. You have a collection, and inside the map or for you reach back to the database once or more per element to assemble the final object.

The real version I fixed did five things per row: fetch the parent record, fetch the parent's latest status, re-fetch an id it already had through a second table, fetch an attribute record, and run an "is this premium?" check that turned out to be several queries by itself. On a few hundred rows that's thousands of statements per request.

Shape 2: the N+1 hiding inside a predicate

This one is sneakier. Somewhere there's a helper like isPremium(planId), and at the call site it reads like plain business logic:

fun isPremium(planId: UUID): Boolean {
    val prices = priceRepo.findByPlan(planId)                  // query 1
    return prices.any { price ->
        val component = componentRepo.find(price.componentId)  // query per price!
        component.type in PREMIUM_TYPES
    }
}

Two problems stacked on top of each other. First, the function is itself an N+1: one query for the plan's prices, then one more per price to resolve the component type. Second, it gets called inside a loop:

val premiumPlanIds = planIds.filterTo(mutableSetOf()) { isPremium(it) }

Total cost: plans × (1 + prices per plan). A predicate that looks like a single if is doing a nested fan-out. These are the worst N+1s to spot, because the expensive part is one function call deep.

The fix: batch first, assemble in memory

Both shapes have the same cure. Do all the fetching up front, in a fixed number of set-based queries, then build the object graph from in-memory maps. The loop stops touching the database entirely.

1. Collect the keys

Before the loop, gather every id you'll need, and de-duplicate. If 1,000 devices sit on 50 sites, you want to fetch 50 sites, not 1,000.

val devices = deviceRepo.findActive()
val siteIds = devices.map { it.siteId }.toSet()

2. One batched query per relationship

Replace findById(x) in a loop with a single IN query:

// Kotlin + Exposed, but every ORM has an equivalent (WHERE id IN (...))
fun findSitesByIds(ids: Set<UUID>): List<Site> = transaction {
    if (ids.isEmpty()) return@transaction emptyList()   // never send IN ()
    SiteTable.selectAll()
        .where { SiteTable.id inList ids }
        .map { it.toSite() }
}

Note the empty-input guard. Depending on your driver, an IN () with no values is either a SQL error or an accidental full-table scan, so short-circuit before you build the query.

Then turn each result into a lookup map keyed on whatever you'll match by:

val sitesById  = siteRepo.findByIds(siteIds).associateBy { it.id }
val datesByKey = assetRepo.installDatesBySiteIds(siteIds)   // Map<Pair<SiteId, Serial>, Date>

3. Assemble against the maps

val rows = devices.map { device ->
    val site = sitesById[device.siteId]
    val date = datesByKey[device.siteId to device.serialNumber]
    Row(device, site, date)
}

The query count no longer depends on the number of devices. It's a fixed handful, one per relationship. 5 rows or 50,000, same count.

"Latest per group" without a query per group

One per-row lookup deserves special mention: "the most recent record for this parent". Done naively that's one ORDER BY created_at DESC LIMIT 1 per parent. You can get all of them in one query with PostgreSQL's DISTINCT ON (elsewhere, ROW_NUMBER() OVER (PARTITION BY ...)):

fun latestWindowsBySiteIds(siteIds: Set<UUID>): List<BillingWindow> = transaction {
    if (siteIds.isEmpty()) return@transaction emptyList()
    BillingWindowTable.selectAll()
        .where { BillingWindowTable.siteId inList siteIds }
        .orderBy(
            BillingWindowTable.siteId to SortOrder.ASC,
            BillingWindowTable.endDate to SortOrder.DESC,   // newest first within each site
        )
        .withDistinctOn(BillingWindowTable.siteId)          // keep first row per site
}

One caveat: check your NULL ordering. If a NULL end-date means "still open", you need to know how your database sorts NULLs. Postgres puts NULLs first under DESC, so an open window is correctly picked as the latest here. Get this wrong and the batched version silently disagrees with the old per-row one, which is exactly the kind of bug that deserves a comment and a test.

Collapsing the nested predicate

The isPremium fan-out disappears once you stop asking one plan at a time. A plan is premium iff any of its price components is a premium type. So fetch all prices for all plans in query 1, fetch all the referenced components in query 2, and match in memory:

fun findPremiumPlanIds(planIds: Set<UUID>): Set<UUID> {
    if (planIds.isEmpty()) return emptySet()

    val prices = priceRepo.findByPlanIds(planIds)            // query 1
    if (prices.isEmpty()) return emptySet()

    val premiumComponentIds = componentRepo
        .findByIds(prices.map { it.componentId }.toSet())    // query 2
        .filter { it.type in PREMIUM_TYPES }
        .mapTo(mutableSetOf()) { it.id }

    return prices                                            // in-memory join
        .filter { it.componentId in premiumComponentIds }
        .mapNotNullTo(mutableSetOf()) { it.planId }
}

Two queries, total, no matter how many plans or components are involved. The old loop cost plans × (1 + prices).

Don't lose per-item error isolation

There's a behavioural trap when you hoist work out of a loop. In the old code, if one item's dependency was missing, you could catch that iteration, mark the item as skipped, and keep going. Batch everything up front carelessly and a single bad row can now fail the whole request.

The fix is to batch the fetching but keep the validation per item:

val (successful, skipped) = devices.map { device ->
    runCatching {
        val site = checkNotNull(sitesById[device.siteId]) {
            "No site for device ${device.id}"
        }
        val window = checkNotNull(windowsBySite[device.siteId]) {
            "No billing window for site ${device.siteId}"
        }
        buildRow(device, site, window)
    }
}.partition { it.isSuccess }

The maps are shared, but each item still gets its own verdict. A device with no billing window lands in skipped with a clear reason and everything else succeeds. Same semantics as the old loop, at the cost of a single batched read.

Prove it with a test that counts statements

A performance fix you can't measure is one you can't defend. "It feels faster" gets refactored away in six months. Milliseconds are noisy and machine-dependent. The durable, deterministic metric is how many SQL statements the operation issues, which happens to be exactly the thing an N+1 blows up.

So I wrote an integration test that runs both implementations against the same seeded data at several sizes, counting statements with a logger that increments on every executed statement:

@Test
fun `batched resolver issues far fewer statements than the per-item loop`() {
    val sizes = listOf(5, 20, 40)
    val newCounts = mutableListOf<Int>()

    sizes.forEach { n ->
        seedItems(upTo = n)

        // 1. Both implementations must agree on the result. Correctness first.
        val oldResult = oldPerItemImplementation()
        val newResult = newBatchedImplementation()
        newResult shouldBe oldResult

        // 2. Then compare statement counts.
        val oldStatements = countStatements { oldPerItemImplementation() }
        val newStatements = countStatements { newBatchedImplementation() }
        newCounts += newStatements

        println("[perf] n=$n | old=$oldStatements | new=$newStatements")
        newStatements shouldBeLessThan oldStatements
    }

    // The real assertion: the new count is flat across every size.
    newCounts.toSet().size shouldBe 1
}

Output looks like this:

[perf] n=5  | old=11 | new=4
[perf] n=20 | old=41 | new=4
[perf] n=40 | old=81 | new=4

Two assertions carry the story. shouldBeLessThan proves the fix is strictly better at every size. The flat-count check proves the new count is identical at 5, 20, and 40 items: O(N) vs O(1) round-trips, encoded as a regression test. If someone reintroduces a per-row lookup, that assertion fails on the spot.

Two notes that saved me grief. Assert equivalence before performance, because a fast wrong answer is still wrong. And count statements with the logger attached, but measure wall-clock in a separate run without it, since the logger distorts timings.

Where this stops being academic

At 5 rows nobody notices an N+1. The reason to fix it is what happens as data grows. Since the queries run sequentially, latency is roughly statements × round-trip time.

Take the assembly loop with 5 lookups per row (1 + N×5 statements) against a batched version at a fixed 6, and assume a healthy 2 ms per round-trip:

Rows (N)	Old statements	New	Old wall-clock	New wall-clock
100	501	6	~1 s	~12 ms
1,000	5,001	6	~10 s	~12 ms
10,000	50,001	6	~100 s	~12 ms

Ten seconds at 1,000 rows means timeouts and a paged on-call engineer. The nested-predicate shape is worse because it multiplies: put isPremium (4 queries per plan) inside the assembly loop and you're at roughly N × M, thousands of statements from that one check before counting anything else. Batching collapses the whole product back to a constant. The win here isn't shaving 20% off a query. It's changing the growth curve.

Wall-clock is also just the symptom the user sees. A request that holds a connection for 10 seconds while it drips out 5,000 queries starves the connection pool for everyone else, so healthy endpoints start failing because of one unbatched loop somewhere else in the service. Every statement gets parsed and planned, and thousands of trivial WHERE id = ? calls burn more database CPU in aggregate than two set-based queries doing the same work. Transactions and locks stay open longer. And the pain concentrates at p99: the average user with a small result set is fine, while the power user with the biggest account hits the worst case every single time. That power user is often your most valuable customer.

A checklist

When an endpoint's latency scales with its result size:

Find the loop that touches the database. Any map/for/filter whose body calls a repository is a suspect. Look inside helper functions too, since the worst N+1s hide one call deep.
Name the shape: 1 + N? 1 + N × k? A nested N × M?
Hoist the fetching out of the loop: collect ids, de-duplicate, one IN query per relationship.
Build maps and assemble in memory. The loop reads from Maps, never the database.
Use DISTINCT ON or window functions for "latest per group".
Collapse nested predicates into "fetch all, match in memory".
Guard empty inputs so you never emit IN ().
Preserve per-item error isolation if the old loop had it.
Lock it in with a statement-count test that asserts a flat count across sizes.

N+1 is a round-trip problem. The individual queries are fine; the count is the enemy. The fix is always the same shape, and the metric that keeps it fixed is statements per operation. Count it, assert it stays flat, and the win becomes a property of the system instead of a mood.

The dotenv gotcha that will eat an afternoon of your life.

Daniel Akudbilla — Sat, 04 Jul 2026 23:59:30 +0000

If you've changed a value in .env and your app keeps using the old one, this is your bug.

TL;DR: dotenv will not overwrite an environment variable that's already set in your shell. If your .env edits aren't taking effect, something else already claimed that variable first. Fix: dotenv.config({ override: true }).

Here's a bug that looks impossible until you know the one rule behind it. dotenv will not overwrite an environment variable that's already set.

That's really the whole article. But the way this bites people is worth walking through, because the symptoms point everywhere except the actual cause.

🔍 The symptom

I had an app reading its OpenAI key from a .env file. Every API call came back 429 insufficient_quota, the classic "you're out of credits" error.

So I checked the obvious things:

The key in .env? Valid. A raw curl with it returned 200.
Billing on the account? Fine.
The right model? Yep.

The same key worked from curl and failed from the app. Same machine, same file, same key. That combination shouldn't be possible, until you realize the app and the curl call weren't actually using the same key at all.

🕵️ The cause

My shell had an old OPENAI_API_KEY exported from a previous experiment, a dead key with no quota left. My curl test used the key directly, so it used the good one. But when the app loaded .env with dotenv, dotenv saw that process.env.OPENAI_API_KEY was already set by the shell, and left the dead key in place.

The .env file was correct the whole time. It was just being ignored.

// This is what everyone writes:
import 'dotenv/config';

// And this is dotenv's rule:
// if process.env.FOO already exists, the .env value is DISCARDED.

🧪 Prove it

Proving it takes about ten seconds. Print the key your code actually sees versus the one in the file:

import 'dotenv/config';
console.log('using key ending in:', process.env.OPENAI_API_KEY?.slice(-6));

If that tail doesn't match your .env, you've found it ✅. Something in your shell (~/.zshrc, ~/.zshenv, a docker run -e, a CI secret, a launchctl setenv) is shadowing the file.

💡 Why dotenv does this on purpose

This isn't a bug. It's standard twelve-factor app behavior, and it's the right default. Real environment variables should outrank a local file. In production, you want the value your platform injected (from Kubernetes, ECS, Heroku, your secrets manager) to win over a stray .env that got left in the image by accident.

The trap only shows up in development, where a leftover export in your dotfiles quietly outranks the file you're actively editing. You change .env, nothing happens, and you start suspecting the network, the API, or the phase of the moon.

🛠️ The fixes

	Fix 1: `override: true`	Fix 2: clean your shell
Best for	Local dev, small/medium apps	Matching prod behavior exactly
Effort	One line, once	Manual cleanup, ongoing discipline
Risk	None in prod (no `.env` there to override)	Easy to forget and re-export later

Fix 1: make your file win (dev-friendly)

import dotenv from 'dotenv';
dotenv.config({ override: true });

Now .env beats the shell during local development. It's still safe in production. If there's no .env file on the server, there's nothing to override, so your platform's real environment variables win by default.

Fix 2: keep dotenv's default behavior, clean your shell instead

echo "$OPENAI_API_KEY"   # find the stale value
unset OPENAI_API_KEY     # kill it for this session

Then track down where it's exported and remove the line:

grep -rn OPENAI_API_KEY ~/.z* ~/.bash* 2>/dev/null

Reach for this option if you specifically want real environment variables to keep top priority, matching production behavior exactly.

🎯 The takeaway

When a config value refuses to change no matter what you put in .env, don't debug the value. Debug which value your process is actually reading:

console.log(process.env.THE_VAR?.slice(-6));

One line, and it turns an afternoon of staring at billing dashboards into a ten-second "oh" 😅. Environment variables set outside your app always outrank your .env, unless you explicitly say otherwise. Now you won't forget it.

If this saved you an afternoon, you probably know someone else who's about to lose one too. Share the word

Happy Coding!

I Built an AI Agent to Check the Weather. It Was Gloriously Unnecessary.

Daniel Akudbilla — Sat, 04 Jul 2026 18:41:37 +0000

Let me get the confession out of the way early: I built an AI agent that, given a city name, tells you about the place and then checks the weather.

You know what already checks the weather? A weather API. One fetch. No model, no tokens, no monthly bill with the word "usage" in it. I knew this the whole time I was building. Built the agent anyway.

Here's the story of that, and a small argument for why doing the unnecessary thing was actually the point.

What the thing does

It's called the Travel & Weather Guide. You type in a city Lisbon, Kyoto, wherever and it gives you back four things: a couple of sentences on what the place is known for, the live weather right now, what people tend to do there this time of year, and a straight verdict on whether now is a good time to visit.

It runs two ways. A web page with a search box:

The Travel & Weather Guide web UI:

And a terminal version, for when you want to feel like a hacker while asking about the weather in Bali:

The CLI starting up, printing "Travel & Weather Guide (type exit to quit)" and prompting for a city name]

Both talk to the same agent underneath. The weather itself comes from Open-Meteo, which is free and needs no key. The "thinking" comes from a model via the OpenAI Agents SDK.

How it actually works (spoiler: not MCP)

The interesting part is how the model gets the weather, because it doesn't. The model can't make an HTTP request or run code, it can only generate text. So instead of fetching anything itself, it asks an internal tool to do it, and waits for the answer.
In the SDK that looks like this:

export const getWeather = tool({
  name: 'get_weather',
  description: 'Fetch current weather for a given city using Open-Meteo.',
  parameters: z.object({
    city: z.string().describe('The city or town name to check weather for'),
  }),
  execute: async ({ city }) => {
    // geocode the city, then hit the forecast endpoint
    // ...return "Lisbon, Portugal: 24°C, wind 12 km/h"
  },
});

That tool() wrapper turns my Zod schema into a description the model can read. So now the model knows a get_weather(city) function exists — but it can't run it. It can only ask.

The loop goes like this:

You ask about Lisbon.
The model thinks, "I need weather data," and emits a structured tool call: get_weather({ city: "Lisbon" }). No code has run yet. That's just the model raising its hand.
The SDK's runner sees the request, runs my actual JavaScript function locally, and that function makes the plain fetch to Open-Meteo.
The result gets handed back to the model.
The model writes the final answer using that data.

People sometimes assume this is MCP. It isn't. MCP is for tools that live in a separate server you connect to over a protocol. This tool is just a function in my own process. The model requests, my code runs, the result goes back. All in-memory, one repo, no protocol.

The uncomfortable part

Look at that loop again. To tell you it's 24°C in Lisbon, the system:

sends the full conversation and tool definitions to a model,
waits for the model to decide it wants the weather,
runs the fetch I could have run in the first place,
sends everything back to the model,
waits again while it writes a paragraph.

Two model round-trips and a pile of tokens, wrapped around a single HTTP call that a first-week bootcamp student could write. The fetch was always the easy part. I built a very expensive middle manager to decide when to make it.

And here's the thing: this isn't just my weird little project. It's the whole moment we're in.

Everything is becoming an agent now

There's a quiet shift happening. A lot of things that used to be a function call, a cron job, or an if statement are being rebuilt as agents. Not because the old way stopped working. The old way is fast and basically free. It's just that "agent" is the shape everything wants to be right now.

Some of that is genuinely good. When a task is fuzzy, open-ended, needs judgment, or strings together tools in ways you can't predict up front, an agent earns its tokens. That's the real use case, and it's legitimately new.

But a lot of it is us wrapping perfectly deterministic problems in a probabilistic, token-metered layer because it feels like the future. We took things that were already solved and made them "smart," which mostly means slower, pricier, and occasionally confidently wrong about the weather. The wins are real. So is the tax. Both things are true at the same time, and nobody wants to say the second one out loud.

My weather agent is a tiny, honest monument to that tax. It is a fetch cosplaying as artificial intelligence.

So why did I build it?

Not to solve a world problem. Let's be very clear. Nobody was out there suffering from a lack of AI-narrated weather. Climate change did not get one degree cooler because my agent can tell you it's warm in Lisbon.

I built it because I did not want to be the guy who talks about agents at parties without having actually built one. You know that guy. I refuse to become that guy.

The agentic era is happening whether I have opinions about tokens or not.

Turns out the best way to understand the expensive absurdity of the agentic era is to commit a small, cheerful act of it yourself.

So no, you should not build an agent to check the weather. You should just call the API.

I, however, have now called the API. Through an agent. On purpose. And I regret nothing, except slightly the tokens. Cheers

Try it yourself

The code is on GitHub: Dakudbilla/openai-travel-weather-agent.

# clone and install
git clone https://github.com/Dakudbilla/openai-travel-weather-agent.git
cd openai-travel-weather-agent
npm install

# add your OpenAI key
cp .env.example .env      # then paste your key into .env: OPENAI_API_KEY=sk-...

npm start                 # web app → http://localhost:3000
npm run cli               # or the terminal version

The weather data is free (Open-Meteo, no key), so the only thing you'll pay for is the tokens.You can get a free openai account generate the API key for it.

Happy Coding

How to Push to a Private GitHub Repository Using a Fine-Grained Personal Access Token

Daniel Akudbilla — Sat, 29 Mar 2025 12:39:25 +0000

If you have an existing local Git repository and need to push it to a private GitHub repository, but GitHub is rejecting your credentials, you may need to use a fine-grained personal access token (PAT). This guide will walk you through the process step by step.

Step 1: Generate a Fine-Grained Personal Access Token (PAT)

GitHub has moved away from password authentication for Git operations, so you must use a personal access token (PAT) instead.

1.1 Navigate to GitHub Settings

Go to GitHub Personal Access Tokens.
Click on "Generate new token (fine-grained)".

1.2 Configure Token Permissions

Repository Access: Select the specific repository you want to push to.
Permissions:
- Under "Repository permissions," set "Read and Write" access for "Contents."
Expiration: Choose an expiration date or select "No expiration" (not recommended for security reasons).
Click "Generate token" and copy the token immediately (you won’t see it again).

Step 2: Set the Remote URL with the PAT

Now, update your Git remote URL to authenticate using the token.

2.1 Navigate to Your Local Repository

Open a terminal and move to your project directory:

cd /path/to/your/local/repository

2.2 Update the Remote URL

Run the following command, replacing {your-personal-token}, {github_username}, and {private-repo-name} accordingly:

git remote set-url origin https://{your-personal-token}@github.com/{github_username}/{private-repo-name}.git

Note: The token will be stored in your Git configuration. For security reasons, it’s best to use a Git credential manager instead of embedding it in the URL.

Step 3: Push Your Code to GitHub

3.1 Add and Commit Changes

If you haven’t already committed your changes, do so:

git add .
git commit -m "Initial commit"

3.2 Push to the Private Repository

Now, push your code to GitHub:

git push -u origin main

If everything is set up correctly, your repository should now be updated on GitHub.

Step 4: Verify Your Push

Go to your GitHub repository and refresh the page. You should see your files successfully pushed.

Optional: Use a Credential Manager for Better Security

Instead of storing your token in the remote URL, you can configure a credential manager to securely store and automatically use your token when needed.

For macOS:

git credential-osxkeychain

For Windows:

git credential-manager-core

For Linux:

git credential-store

Then, configure Git to use the credential manager:

git config --global credential.helper store

This way, you won’t need to include your token in the remote URL manually.

Conclusion

By following these steps, you should be able to push to a private GitHub repository using a fine-grained personal access token. This method ensures secure authentication without exposing your GitHub password. Always remember to keep your access tokens safe and use GitHub's credential storage features for added security.

Cloning a Private GitHub Repository Using HTTPS

Daniel Akudbilla — Mon, 03 Mar 2025 20:52:56 +0000

If you're here, you're either struggling to clone a private GitHub repository or simply trying to learn how. Let's dive straight into the solution.
You have encountered this error
Cloning into 'repo_name'... remote: Write access to repository not granted. fatal: unable to access 'https://github.com/username/repo_name.git/': The requested URL returned error: 403

Step 1: Generate a Personal Access Token (PAT)

To clone a private repository using HTTPS, you need a Personal Access Token (PAT) instead of a password. Follow these steps to generate one:

1. Log in to GitHub

Go to GitHub and sign in to your account.
Click on your profile picture in the top-right corner.
Select Settings.

2. Navigate to Developer Settings

Scroll down and click on Developer settings (found in the left sidebar).
Under Personal access tokens, select Fine-grained tokens.
Click Generate new token.

3. Configure the Token

Name the token (e.g., GitHub Repo Access).
Select the resource owner: Choose your GitHub username (or your organization if cloning an organization repo).
Set an expiration date: Choose an appropriate duration for security purposes.
Repository access:
- Select All repositories (if you want access to all your repos).
- Recommended: Select only the specific repositories you need access to.
Permissions:
- Under Repository permissions, find Contents and set it to Read and Write.
- Find Administration and set it to Read and Write.
- Grant additional permissions as needed.

4. Generate and Copy the Token

Click Generate Token.
Important: Copy the generated token and store it securely, as it will not be shown again.

Step 2: Clone the Private Repository

With your Personal Access Token (PAT) ready, follow these steps to clone your private repository:

1. Open Your Terminal

On Windows, use Git Bash or Command Prompt.
On Mac/Linux, use the Terminal.

2. Run the Clone Command

Use the following command to clone your repository:

git clone https://USERNAME:TOKEN@github.com/USERNAME/REPOSITORY_NAME.git

Replace:

USERNAME → Your GitHub username
TOKEN → Your generated Personal Access Token
REPOSITORY_NAME → The name of your repository

Example:

git clone https://johnDoe:ghp_ABC123xyz@github.com/johnDoe/my-private-repo.git

If everything is correct, your repository should start cloning successfully.

Final Thoughts

I personally struggled with this issue for a while and decided to share my findings after thorough research. I hope this guide helps you avoid the same frustration. If you found this useful, share it with others who might need it!

🚀 Happy coding!