Skip to content

GitHub

2 posts with the tag “GitHub”

GitHub Actions' "Deranged" Sleep Loop: Years of Bugs Costing Developers Thousands

GitHub Actions, the ubiquitous CI/CD platform powering workflows for millions of repositories, harbors a notorious four-line Bash function that’s been lambasted as “utterly deranged” by programming luminaries. This sleep mechanism, meant to pause execution briefly, has instead spawned infinite loops, zombie processes, and runaway bills—issues persisting for nearly a decade despite fixes sitting unmerged.

The saga begins around 2016 with the initial public commits to the GitHub Actions runner codebase. Early versions reveal Windows developers grappling with Bash scripting, resorting to a Stack Overflow hack from 16 years prior: using ping to simulate a 5-second delay when sleep wasn’t available.

Terminal window
if [ $? -eq 4 ]; then
sleep 5 || ping -n 6 127.0.0.1 > nul || (for i in `seq 1 5000`; do echo >&5; done)
fi

This fallback chain—sleep first, then ping -n 6 (yielding ~4 seconds), or worst-case, echoing to /dev/null 5,000 times—earned promotion to a top-level safe_sleep function. It was crude but mostly functional, if CPU-intensive.

By 2022, evolution took a darker turn. The code “improved” into this gem, which lingered for years:

Terminal window
start=$SECONDS
while [ $((SECONDS - start)) -ne ${1?} ]; do :; done

At first glance, it leverages Bash’s SECONDS variable (incrementing every second) for a precise wait. Pass 5, and it loops until exactly 5 seconds elapse. But here’s the fatal flaw: on busy CI runners juggling heavy jobs, loop iterations might skip seconds due to scheduling delays. If SECONDS - start jumps from 4 to 6, -ne 5 never falsifies, trapping the process in an eternal spin.

Worse, with no sleep inside the loop, it pegs a full CPU core at 100%—half the compute on GitHub’s standard 2-vCPU runners—starving other tasks and cascading failures across queues.

Real-World Carnage: $2,400 Zombie Processes and CI Meltdowns

Section titled “Real-World Carnage: $2,400 Zombie Processes and CI Meltdowns”

The fallout was brutal. One developer reported a single runner idling for 5,135 hours, billed at GitHub’s $0.08 per vCPU-minute rate: ~$2,400 vaporized. Projects like Zigg abandoned GitHub entirely for Codeberg, citing “inexcusable bugs” and “vibe scheduling” post-Microsoft’s AI pivot—random job prioritization exacerbating backlogs where even main branch commits stalled.

A simple fix emerged in 2024: tweak to while [ $((SECONDS - start)) -le ${1?} ]; do :; done. This embraces overshoot, halting reliably. Proposed in February 2022, it languished, auto-closed after a month, then merged 1.5 years later amid outcry—yet other bugs persist, like recent file-hashing failures from a botched refactor.

That refactor? A JavaScript snippet trading a clean Object.getOwnPropertyNames for nested loops and redundant if statements, ballooning complexity and introducing regressions.

// Pre-refactor simplicity vs. post-refactor horror
function getKeys(obj) {
return Object.getOwnPropertyNames(obj);
}
// Now: convoluted for-loops, duplicated code, function-returning-functions

GitHub Actions underpins a multi-billion-dollar Microsoft ecosystem, yet these gremlins fester. PRs ignored, refactors worsening code, neglect amid scale: it’s a stark reminder that even giants stumble on fundamentals. Proponents argue it’s “elegant Bash”—short, using : as a no-op—but critics like Matt Lad, of Antithesis, nail it: peak engineering this is not.

Recent AI hype restores ironic faith; no LLM could conjure such creatively catastrophic logic. Developers pay premium for reliability—GitHub must prioritize core stability over shine. Until then, audit your runners: that “harmless” sleep might be your budget’s silent killer.

But why would they fix it? This isn’t just “neglect”; it’s a symptom of monopoly lethargy. When you own the ecosystem—when millions of workflows are locked into your syntax—performance bugs that burn customer CPU cycles are, perversely, revenue generators. Every wasted minute of a zombie runner is a minute billed. In a competitive market, this would be a death sentence. In GitHub’s world, it’s a rounding error. The real fix isn’t just a patch; it’s viable competition that forces the giant to care about the ants.

Atom The IDE That Accidentally Built its Own Killer

On June 25, 2015, Chris Wanstrath celebrated Atom 1.0’s stable release—a free, open-source code editor built on web technologies that promised to democratize development. What started as a passion project in 2007, sparked by a chance meeting at a Ruby meetup where Wanstrath encountered Tom Preston-Werner demoing an early GitHub prototype called Grit, evolved into a hackable editor inspired by Emacs but powered by HTML, CSS, and JavaScript.

Atom’s journey wasn’t smooth. Shelved amid GitHub duties, it revived in 2011 using the ACE editor in a WebView, then pivoted to Chromium Embedded Framework and Node.js via Node-WebKit in 2012. This fusion birthed “Atom Shell”—a tool so potent it was rebranded Electron in 2015, decoupling it from Atom to fuel cross-platform desktop apps.

Electron’s appeal was immediate: leverage familiar web stacks for native-like apps, sidestep C++ hurdles of frameworks like Qt, enable rapid iterations, and reuse web codebases. Developers flocked to it for projects beyond editing, and giants followed—Slack, Discord, Microsoft Teams all run on Electron today, powering billions of interactions.

Atom’s 2014 beta exploded in popularity amid a surge in new programmers, its lightweight design and package ecosystem outshining bloated incumbents like Visual Studio. Backlash over its initial closed-source status echoed Wanstrath’s open-source advocacy, but relicensing under MIT quelled critics, growing its user base to over 1.1 million.

Yet Electron’s bloat—bundling full Chromium and Node.js per app—haunted performance. Atom took seconds to open small files, guzzling 400MB RAM. Enter Microsoft’s Visual Studio Code (VS Code) in 2015, built on Monaco (evolved from their browser editor) and Electron. Skeptics dismissed it, but optimizations shone: isolated extension processes, pre-optimized Monaco, binary encoding. VS Code launched 4x faster, went fully open-source, and birthed a thriving marketplace.

The 2018 Microsoft-GitHub acquisition for $7.5B raised alarms. New CEO Nat Friedman promised dual support on Reddit, but reality diverged—VS Code iterated monthly while Atom stagnated, commits plummeting 76% in six months. By 2022, Atom sunsetted, repositories archived by late 2022, with Microsoft pivoting to cloud tools like GitHub Codespaces. Community forks like Pulsar emerged, but Atom’s era ended.

Atom’s legacy? Electron endures. VS Code dominates 2025 surveys—15-54% market share per PYPL and Stack Overflow data—holding off AI challengers despite Cursor’s 18% adoption and Zed’s buzz. Cursor, a VS Code fork with AI-native features like Composer and Visual Editor, hit $500M ARR by mid-2025, serving half the Fortune 500 with real-time collaboration and agent workflows. Zed, Rust-powered by ex-Atom contributors, gained Windows support in October 2025, previewing Dev Containers and AI commits, amassing momentum.

Electron powers it all: VS Code’s blinking cursors carry Atom’s ghost. In open source, death spawns successors—Zed’s 70K+ stars, Cursor’s explosive growth. As 2025 Stack Overflow data shows developers craving AI tools atop proven editors, Atom didn’t lose; its killer became the industry standard, forked eternally.

But there’s a deeper story here than just software genealogy. Zed isn’t just a spiritual successor; it’s a personal redemption. Nathan Sobo, the original creator of Atom, is also the architect behind Zed. For him, the pivot from Electron (which he helped pioneer) to Rust wasn’t just a technical decision—it was a correction of his own legacy’s greatest flaw: performance. In an industry obsessed with “new,” there’s profound poetry in a creator returning to fix what he broke, proving that open source isn’t just about codebases, but about the people who learn, fail, and build again.