A Go concurrency bug that's easy to miss (and how to catch it) Ran into this in a production serv...

A Go concurrency bug that's easy to miss (and how to catch it) Ran into this in a production serv...A Go concurrency bug that's easy to miss (and how to catch it) Ran into this in a production serv...

The network for creativity

Join 1.25M professional creatives like you

Connect with clients, get discovered, and run your business 100% commission-free

Creatives on Contra have earned over $150M and we are just getting started

Back to feedPost

Jitendra Kumar

• Sep 11

A Go concurrency bug that's easy to miss (and how to catch it)

Ran into this in a production service last month — a classic goroutine leak that didn't show up until load testing.

The pattern looked innocent:

func processOrders(orders <-chan Order) {
    for order := range orders {
        go func() {
            handle(order) // bug: order is captured by reference
        }()
    }
}

Before Go 1.22, order was a shared loop variable — every goroutine could end up processing the same (usually last) order instead of its own. Even after the Go 1.22 fix, it's worth knowing why this broke so many codebases for years.

The fix (pre-1.22 style, still good practice for clarity):

for order := range orders {
    order := order // shadow it
    go func() {
        handle(order)
    }()
}

Or simpler — pass it as a parameter:

go func(o Order) {
    handle(o)
}(order)

Small thing, but it's the kind of bug that only shows up under concurrent load — never in a quick local test. Worth a lint rule or code review checklist item if your team ships concurrent Go code.

Dana Morozova

• Sep 14

New set of 3D error/empty state icons 🧡 No connection, payment declined, 404, locked profile, notifications off - a few of those "painful" app screens, done in my signature orange/navy style. This is actually my second set like this - the first one was in a completely different visual language, so it's fun to see how much the approach has changed 👀

Icon Designer Illustration UX Design Figma

Roman Verbytskyi

• Sep 14

very interesting icons, good job Dana🙌

Bearplus Fullstack Agency

• Sep 14

The 404 was treated as a proper page rather than a fallback state.

The number is constructed as an architectural drawing. The 4 and the 0 are formed from walls at true thickness, with furniture laid out inside the resulting rooms and dimension strings running along both edges. It sits inside the same drafting system as the rest of the site rather than borrowing a display typeface.

The error message then repeats. Instead of a single dialog, identical windows cascade back across the canvas, each one carrying the same 404 notice. It reads as a system throwing an unresolved warning over and over, which is the exact behaviour Heron is built to prevent inside a model.

Error pages are never in the brief. They're a good measure of whether a team understood the product or just styled it.

Web Development Interaction Design 404page Architecture UI Design Web Design GSAP three.js Webflow

Diego Sánchez

• Sep 15

Treating a 404 as an actual page instead of a dead end is such a good instinct, where did the architectural drawing idea come from, personal interest bleeding into the work?