DEV Community: Emre Ozsahin

Goroutines and channels

Emre Ozsahin — Fri, 17 Jul 2026 20:08:04 +0000

Goroutines and channels

While building RagPack, I needed a file worker that would parse file chunks and write them into LanceDB, an embedded columnar vector database. This would have been fiddly to get right in most languages, but Go's concurrency primitives made it simple without any major architectural shift. Here's how goroutines, channels, and sync.WaitGroup work together in the ingestion pipeline.

What are goroutines?

Goroutines, just like coroutines in Kotlin, are lightweight concurrency units managed by the Go runtime. The runtime multiplexes many goroutines onto a much smaller number of OS threads, so spawning thousands of them is cheap.

Launching one is one line:

go func() {}()

In my case, I spawn a fixed number of worker goroutines based on the configured worker count:

for i := 0; i < workers; i++ {
  wp.waitGroup.Add(1)
  go wp.run(ctx)
}

Since each goroutine runs independently, something has to coordinate handing off work between them and knowing when they're actually done. That's where channels and WaitGroup come in, and they solve two completely different problems.

Channels move the work

A channel is the communication layer between concurrent goroutines, where each can send and receive values safely, without explicit locks or race conditions.

In my case, workers pull queued items off a shared channel:

type queueItem struct {
    job    meta.Job
    reader io.ReadCloser
}

queue := make(chan queueItem, workers*10)

Data flows through the <- operator:

Send to a channel: ch <- item
Receive from a channel: item := <-ch

There are two flavors, and they behave differently based on capacity:

Unbuffered channels have no capacity to hold data. A send blocks the sender until a receiver is ready, and a receiver blocks until a sender sends. This synchronizes the two goroutines directly.

Buffered channels are created with a fixed capacity, like make(chan queueItem, 10). Sending only blocks once the buffer is full, receiving only blocks once it's empty. That decouples the timing of sender and receiver, which is why my queue channel above is buffered at workers*10, it lets jobs pile up a bit without forcing whoever's submitting them to wait on a free worker.

Sending on an unbuffered channel with nobody reading deadlocks the whole program:

func main() {
    ch := make(chan queueItem)
    ch <- queueItem{} // ERROR: deadlock, nothing is ever reading from ch
}

Each worker in my pool avoids this by always being ready to receive, looping on a select that watches both the queue and cancellation:

func (wp *WorkerPool) run(ctx context.Context) {
    defer wp.waitGroup.Done()
    for {
        select {
        case <-ctx.Done():
            return
        case item := <-wp.queue:
            if err := wp.processJob(ctx, item); err != nil {
                log.Printf("ingester: job %s failed: %v", item.job.ID, err)
            }
        }
    }
}

This is what makes the producer/consumer pattern so easy in Go. There's no thread pool to manage and no lock to take, just a channel read in a loop.

WaitGroup answers a different question

I initially assumed WaitGroup was somehow gating the channel, blocking new work until a slot opened up. It isn't, and it has no idea what a channel even is. It's a plain counter with three methods:

Add(n): increments the counter by n, called before spawning the goroutines you want tracked
Done(): decrements the counter by one, called by each goroutine when it finishes, usually via defer
Wait(): blocks the calling goroutine until the counter hits zero

What it actually answers is: "have all the goroutines I started actually finished?" Canceling ctx tells workers to stop picking up new jobs, but it says nothing about a job already in progress. A worker could be mid-write to LanceDB the instant ctx is canceled, and if the process exits right then, that write is lost.

func (wp *WorkerPool) Stop() {
    wp.waitGroup.Wait()
}

Stop() is called after the context is canceled, and it blocks until every worker's deferred wp.waitGroup.Done() has actually run, meaning every in-flight job finished processing first. Skip this and shutdown becomes a race: clean most of the time, but occasionally losing the tail end of whatever a worker was writing.

Putting it together

run and Stop above are two of the three moving pieces. The dispatcher ties them together:

func (wp *WorkerPool) Start(ctx context.Context, workers int) {
    go wp.loop(ctx, workers)
}

func (wp *WorkerPool) loop(ctx context.Context, workers int) {
    for i := 0; i < workers; i++ {
        wp.waitGroup.Add(1)
        go wp.run(ctx)
    }

    for {
        select {
        case <-ctx.Done():
            return
        }
    }
}

Start kicks off the dispatcher in its own goroutine. The dispatcher spawns the fixed pool of workers, each incrementing the shared WaitGroup before it starts. Every worker pulls from the same queue channel until the context is canceled. Stop is the only place that actually confirms shutdown is done, not when the context is canceled, but when the last worker's Done call lands.

Three primitives, three separate jobs: goroutines run the work, the channel distributes it, WaitGroup confirms it's finished.

Happy coding!

Publishing to the VS Code Marketplace with CI

Emre Ozsahin — Fri, 10 Jul 2026 03:29:08 +0000

Publishing to the VS Code Marketplace with CI

While setting up CI for LanceDB Explorer, a VS Code extension I built for browsing LanceDB databases, I wanted git tag vX.Y.Z && git push to publish straight to the VS Code Marketplace.

The obvious way is a Personal Access Token: generate one in Azure DevOps, drop it in a GitHub secret, done. But global Azure DevOps PATs are being retired on December 1, 2026, and Microsoft's own publishing docs now point everyone toward Entra ID instead: OIDC through a managed identity, a federated credential, and one undocumented API call to find the right ID. That page covers the Azure Pipelines version. I spent way more time than I expected getting this to actually work, mostly guessing at IDs the Marketplace would not recognize. This is the GitHub Actions version, spelled out the way I wish I had it going in.

Requirements

An Azure account with an active subscription. A free tier subscription is enough, a managed identity is a real Azure resource so it needs somewhere to live.
A GitHub repo with Actions enabled, and permission to add repo secrets.
A publisher created on marketplace.visualstudio.com/manage (sign in with a Microsoft account, + Create publisher, pick an ID). Nothing else in this post works without this, the managed identity you set up later gets authorized against this specific publisher. Put its ID in your extension's publisher field in package.json.
The Azure CLI (az) if you want to run the identity lookup in step 4 locally instead of as a throwaway GitHub Actions job.

Step 1: create a user-assigned managed identity, not an App Registration

Use a managed identity, not an App Registration. An App Registration is free and needs no subscription, so it looks like the right choice, but it authenticates fine and then fails at the actual publish step with InvalidAccessException: The requested operation is not allowed. Only a managed identity works here.

Go to portal.azure.com and sign in.
In the search bar at the top, type Managed Identities and click the matching result. Do not use the generic "Create a resource" button, it buries this under a category picker.
Click + Create.
Fill in: your subscription, a resource group (create a new one if you do not have one already), a region (any region is fine), and a name for the identity (for example vscode-publisher).
Click Review + create, then Create. Wait for the deployment to finish, then click Go to resource.

Step 2: add a federated credential for GitHub Actions

This step tells Azure to trust GitHub Actions, so it can hand out short-lived tokens without you storing a password anywhere.

On the same managed identity resource, in the left menu click Settings, then Federated credentials.
Click + Add credential.
Under Federated credential scenario, choose GitHub Actions deploying Azure resources.
Fill in:
- Organization: your GitHub username or org name
- Repository: the name of your repo (just the repo name, not the full URL)
- Entity type: choose Environment
- GitHub environment name: type a name for this, for example marketplace-publish. Write this down exactly, you will type it again later in your workflow file.
Give the credential a Name (any label works, for example github-actions) and click Add.

Use Environment here, not Branch or Tag. If you pick Tag, the trust only matches one exact tag name, and it breaks the moment you push a second release.

Step 3: add the GitHub Actions secrets

First grab the two values you need. On the managed identity resource, in the left menu click Settings, then Properties. Copy the values labeled Client ID and Tenant ID.

Then:

Open your repo on GitHub in a browser.
Click the Settings tab (top of the repo page, not your account settings).
In the left menu, click Secrets and variables, then Actions.
Click New repository secret.
Name it AZURE_CLIENT_ID, paste the Client ID, click Add secret.
Click New repository secret again. Name it AZURE_TENANT_ID, paste the Tenant ID, click Add secret.

Every azure/login step later in this post reads these two secrets by these exact names, so they need to exist before anything else here will work.

Step 4: find the ID the Marketplace actually wants

This is the part that is not documented anywhere I could find. The VS Code Marketplace runs on Azure DevOps under the hood, and Azure DevOps keeps its own internal identity record, separate from both the managed identity's ARM resource ID and its Entra Object ID. A managed identity that has never talked to Azure DevOps before does not have a profile there yet, so trying to add it to your publisher by either of those IDs will just come back "not found."

The fix is one API call, made once, while authenticated as the identity:

az rest -u https://app.vssps.visualstudio.com/_apis/profile/profiles/me \
  --resource 499b84ac-1321-427f-aa17-267ca6975798

That GUID is Azure DevOps's well-known app ID in Microsoft Entra, documented here as the resource ID to use when requesting Entra tokens for Azure DevOps. It is the same for every organization, not something specific to your setup. Calling this endpoint registers the identity with Azure DevOps and returns its ID in Azure DevOps's own terms:

{
  "displayName": "...\\<entra-object-id>",
  "id": "<the ID that actually works>",
  "publicAlias": "<same as id>"
}

The easiest way to run this once is a throwaway workflow_dispatch job:

name: Debug Identity
on: workflow_dispatch
permissions:
  id-token: write
  contents: read
jobs:
  debug:
    runs-on: ubuntu-latest
    environment: marketplace-publish
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          allow-no-subscriptions: true
      - run: az rest -u https://app.vssps.visualstudio.com/_apis/profile/profiles/me --resource 499b84ac-1321-427f-aa17-267ca6975798

To run it:

Save that YAML as a new file, for example .github/workflows/debug-identity.yml, commit it, and push.
On GitHub, click the Actions tab of your repo.
In the left list of workflows, click Debug Identity.
Click the Run workflow button, then confirm.
Wait a few seconds, then click into the run that appears, then click the debug job.
Expand the last step in the log. You will see a block of JSON, find the line that says "id": "..." and copy that value.
Delete the workflow file and push again, you only need it this once.

Step 5: authorize the identity on your publisher

Go to marketplace.visualstudio.com/manage, sign in, and select your publisher.
Look for a Members section (in some views this is under a settings or gear icon near the publisher name).
Click Add (or the equivalent button to add a member).
Paste the id value from step 4 into the search or ID field. Use that value specifically, not the managed identity's Client ID, Tenant ID, or Resource ID, none of those are recognized here.
Set the role to Contributor and save.

If this does not find the identity, you likely pasted the wrong value. The only ID this search recognizes is the one from step 4's API call.

Step 6: the actual publish workflow

permissions:
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: marketplace-publish
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - uses: actions/download-artifact@v4
        with:
          path: artifacts
          merge-multiple: true
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          allow-no-subscriptions: true
      - run: npx vsce publish --packagePath artifacts/*.vsix --skip-duplicate --azure-credential

No VSCE_PAT, no client secret, nothing to rotate or expire. For the full CI/CD workflow, including the build matrix that produces artifacts/*.vsix in the first place, see release.yml in the LanceDB Explorer repo.

Resources

Happy coding!

Cutting Vercel Fluid CPU with Next.js Server-Side Caching

Emre Ozsahin — Mon, 06 Jul 2026 22:38:03 +0000

Cutting Vercel Fluid CPU with Next.js Server-Side Caching

Got an email from Vercel about reaching limits and checked to see Fluid Active CPU spiking for worldcuppicks.co. Obviously I don't want to go to premium, so I implemented certain measures to bring it down. We are in the knockout rounds now, so I wanted to get it sorted before things got worse.

First identification

Going to the Vercel Observability tab, I was able to see which page was causing the heavy load. The home page function was clocking nearly 3 minutes of active CPU time per billing window while every other route measured in seconds. That pointed me straight at the problem: the home page was doing two full database fetches on every single visit, for every user, with no caching in between.

// This ran on every page visit, for every user
const [matches, predictions] = await Promise.all([
  getAllMatches(),
  getAllMatchPredictions(),
]);

getAllMatches joins across three tables. getAllMatchPredictions pulls aggregate pick stats. Both were uncached, so every visit hit the database from scratch.

The second culprit was Sentry. I had it configured with a tunnelRoute that proxies Sentry events through a Vercel function at /monitoring. Every page load was generating an extra function invocation. I disabled Sentry entirely for now and that brought the baseline down.

The fix: unstable_cache

Next.js ships a function called unstable_cache that wraps any async function with a server-side cache. The result is shared across all users and all requests, not per session. The first request after a cache miss hits the database, and every subsequent request gets the cached result.

For matches I set revalidate: false, meaning the cache never expires on a timer:

export const getAllMatches = unstable_cache(
  async (): Promise<Match[]> => {
    const supabase = getOrCreateAdminClient();
    const { data } = await supabase
      .from("matches")
      .select(`*, home_team:teams!home_team_id(...), away_team:teams!away_team_id(...)`)
      .order("match_date", { ascending: true });
    return (data as Match[]) ?? [];
  },
  ["all-matches"],
  { revalidate: false, tags: ["matches"] }
);

Match data only changes when I update it from the admin panel, so a time-based TTL adds nothing. The admin server action calls revalidateTag("matches") the moment a match is saved, which busts the cache immediately:

const { error } = await supabase.from("matches").update(update).eq("id", matchId);
if (error) throw new Error("Failed to update match");
revalidatePath("/admin");
revalidateTag("matches");
revalidateTag("predictions");

For prediction stats I went with a one-hour TTL as a fallback:

export const getAllMatchPredictions = unstable_cache(
  async (): Promise<MatchPredictionStats[]> => {
    const supabase = getOrCreateAdminClient();
    const { data } = await supabase.from("match_predictions").select("*");
    return (data ?? []) as MatchPredictionStats[];
  },
  ["all-match-predictions"],
  { revalidate: 3600, tags: ["predictions"] }
);

Why stale prediction stats are fine

The obvious concern is that cached prediction percentages go stale. Won't someone loading the page see wrong crowd percentages?

But the crowd percentage bar uses a Supabase realtime subscription on the client. The moment a pick is submitted, Supabase pushes the updated row to every connected browser over a WebSocket. The cached server data is only used for the initial SSR render. Within milliseconds of hydration, realtime takes over.

The user's own pick is handled via optimistic local state, so it's instant regardless:

async function handlePick(newPick: Pick) {
  setPick(newPick); // instant, before the server action returns
  await submitPrediction(matchId, newPick);
}

The key insight

unstable_cache is shared across all requests on the server, not per session. Without it, every page visit queries the database for the exact same data. With it, it's one query until the cache is busted. For match data that only changes when I update it from the admin panel, that's the right trade.

Happy coding!

TIL: Streaming Data in Go with iter and yield

Emre Ozsahin — Sat, 04 Jul 2026 03:06:54 +0000

TIL: Streaming Data in Go with iter and yield

While building RagPack, a library that chunks files for embedding, I needed a common way to stream parsed content from multiple file formats. RagPack supports CSV, PDF, DOCX, HTML, XLSX, Markdown, JSON and more. Each format has its own parser, but the ingester that consumes them should not care which one it is talking to. I needed a shared contract. In Java I would have reached for an Iterator<T> or an InputStream, but in Go the answer turned out to be the iter package, introduced in Go 1.23.

The Parser interface

The iter package introduces two types. Seq[V] yields a single value at a time, and Seq2[K, V] yields a pair:

type Seq[V any]     func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)

Seq2 is the right fit here because each iteration naturally produces two things: a parsed unit and any read error. This matches Go's standard (value, error) convention and lets the caller handle errors inline without wrapping them in a struct.

That made iter.Seq2[Unit, error] a natural return type for the Parser interface:

type Parser interface {
    Parse(ctx context.Context, r io.ReadCloser) iter.Seq2[Unit, error]
}

Every sub-parser, CSVParser, PDFParser, DocxParser, HTMLParser and so on, implements this one method. The ingester does not need to know which format it is dealing with.

Implementing a parser

Here is what a parser implementation looks like:

func (p *Parser) Parse(_ context.Context, r io.ReadCloser) iter.Seq2[Unit, error] {
    return func(yield func(Unit, error) bool) {
        defer r.Close()

        reader := bufio.NewReader(r)
        for {
            line, err := reader.ReadString('\n')
            if err == io.EOF {
                break
            }
            if err != nil {
                yield(Unit{}, err)
                return
            }
            if !yield(Unit{Text: strings.TrimRight(line, "\n")}, nil) {
                return
            }
        }
    }
}

The if !yield(...) { return } part is the key. If the caller breaks out of the loop early, yield returns false and we stop reading. No wasted work.

Using it with range

Because all parsers return the same type, the ingester ranges over any of them the same way:

for unit, err := range parser.Parse(ctx, file) {
    if err != nil {
        // handle error
    }
    embed(unit)
}

Swap in a different parser and the loop does not change. That is one big win. Memory was also in our minds when designing this. For streaming formats like CSV, JSON, or plain text, yielding one unit at a time keeps the footprint flat no matter how large the file is. For formats like PDF it is a bit more nuanced since the underlying parser has to load the full file first to parse it.

Happy coding!