fsck.sh - English

Symfony Messenger Worker Stuck? 3 Silent Production Bugs

2026-02-27T00:00:00Z

Sixteen minutes. Three bugs. Zero errors.

Or: How Symfony Messenger convinced us everything was fine while doing absolutely nothing

We deployed a Symfony Messenger worker to production, watched it start, saw the familiar [OK] Consuming messages from transport "bulk_operations" in the logs, and moved on. Messages piled up. The worker sat idle. No exceptions, no warnings, no failed jobs. Just silence.

What followed was a 16-minute debugging session that uncovered three independent bugs, each one invisible in its own way. Here’s the timeline.

TL;DR: Three bugs, three silent failures. (1) auto_setup=0 in the DSN meant the messenger_messages table was never created — the worker logs OK anyway. (2) use_notify: true is PostgreSQL-only; MySQL ignores it and never falls back to polling. (3) PHP-FPM wrote Europe/Berlin timestamps while PHP CLI read them as UTC, delaying every background job by exactly one hour.

The Setup

The environment: Symfony 6.2, PHP 8.1, MySQL 8.0 on a bare-metal Ubuntu server. All findings below are specific to this stack — behaviour may differ across Symfony versions or with the Redis/AMQP transports. The background worker runs as a systemd service (a standard Linux mechanism for managing long-running background processes):

# /etc/systemd/system/messenger.service ExecStart=/usr/bin/php /var/www/app/bin/console messenger:consume bulk_operations --time-limit=3600 --memory-limit=128M User=www-data

The transport uses Doctrine:

# config/packages/messenger.yaml framework:  messenger:  transports:  bulk_operations:  dsn: "%env(MESSENGER_TRANSPORT_DSN)%"  options:  use_notify: true  check_delayed_interval: 60000

And the DSN in .env:

MESSENGER_TRANSPORT_DSN=doctrine://default?auto_setup=0

Three configuration decisions. Three bugs. Let’s walk through them in the order we found them.

Why Does Messenger Fail With a Missing ‘messenger_messages’ Table?

The messenger_messages table didn’t exist.

The DSN had auto_setup=0, which tells Symfony’s Doctrine transport not to create its queue table automatically. This is a reasonable production setting — you don’t want your app creating database tables on the fly. But it assumes you’ve created the table yourself. We hadn’t.

Here’s the thing: messenger_messages isn’t a Doctrine entity. There’s no migration for it, no entity class, nothing in src/Entity/. It’s an internal transport table that Symfony manages outside your ORM layer. If you don’t let the transport create it and you don’t create it manually, it simply doesn’t exist.

The worker’s response to a missing table? [OK] Consuming messages from transport "bulk_operations". No error. No warning.…

Continue reading on fsck.sh →

Hunting a 0.18% Bug: Redis Lock Expiration in Crunz

2026-02-10T00:00:00Z

When “sporadic” means “mathematically inevitable”

In RedisStore.php line 185: [Symfony\Component\Lock\Exception\LockConflictedException]

One line. No stack trace. No context. Just a LockConflictedException showing up in our crunz scheduler logs — every single day. Sometimes once, sometimes a dozen times. No clear pattern, no obvious trigger. A textbook non-deterministic bug.

I ignored it for a while. Then I did the math.

Turns out this wasn’t random at all. It was a probabilistic certainty baked into crunz’s lock refresh mechanism — a bug that hits roughly 1 in every 550 lock operations. With 42 Redis-locked cron jobs running on schedules throughout the day, the question was never if it happens, but how often.

What’s a Lock, and Why Does It Expire?

If you’re already comfortable with distributed locking and mutual exclusion, skip ahead. For everyone else — a quick mental model.

Think of a lock like a parking meter. You feed it coins (a TTL — time to live), and as long as there’s time on the meter, the parking spot is yours. Nobody else can take it. But the moment it runs out, the spot is fair game — even if you’re still in the store buying groceries.

Redis locks work the same way. Crunz — a PHP cron job scheduler — uses the Symfony Lock component with a RedisStore to prevent overlapping task execution. When a task starts, it acquires a lock with a time limit via ZADD (Redis’s “sorted set add” command — it stores a unique token with a score representing the expiration timestamp). As long as the task keeps refreshing that lock before it expires, it’s safe. But if the refresh comes too late — even by a fraction of a second — Redis considers the lock gone. The next refresh attempt finds an empty spot and throws LockConflictedException.

The twist: crunz doesn’t refresh the lock reliably. It uses a probabilistic approach. More on that in a moment.

Redis Distributed Locks in PHP

A distributed lock with Redis ensures that only one process runs a critical section at a time — even across multiple servers. In PHP, the Symfony Lock component makes this straightforward. Here’s a basic Redis lock example:

use Symfony\Component\Lock\LockFactory; use Symfony\Component\Lock\Store\…

Continue reading on fsck.sh →

PHP: The Cockroach of Programming Languages (And Why That's a Compliment)

2026-01-29T00:00:00Z

Unkillable, unfashionable, undeniably employed

In 2011, an article titled “PHP is Dying” made its rounds. The author predicted that within five years, PHP would be relegated to legacy maintenance. That was 15 years ago. PHP still powers 73.3% of websites with detectable server-side technology (W3Techs, January 2026).

I’ve been writing PHP since 2002. For 15 of those years, it’s been my primary income as a freelancer. I’ve worked with Symfony since version 2. And every few years, someone confidently tells me my career choice is dying.

They’re still wrong. But they’re not entirely without points.

The Critics Have Some Points

Let’s be honest: PHP has real problems. Acknowledging them makes us better developers, not disloyal ones.

The stdlib is chaos. Parameter order is inconsistent (strpos($haystack, $needle) vs array_search($needle, $haystack)). Naming conventions are all over the place (str_replace vs substr vs string_starts_with). This isn’t defensible. It’s historical baggage from rapid, community-driven growth in the early years.

Unicode handling is bolted on. You need mb_* functions for proper multibyte support, and forgetting to use them causes subtle bugs. In 2026, this still isn’t first-class.

Legacy code gives PHP a bad name. A lot of PHP in the wild is genuinely awful. Unmaintained WordPress plugins, spaghetti from 2008, raw SQL everywhere. When critics say “PHP code is bad,” they’re often looking at code that would be bad in any language, but PHP’s low barrier to entry means there’s more of it visible.

These are legitimate criticisms. If someone focuses on these points, they’re being fair.

Why the Myth Persists

So if PHP has real problems, why do I call “PHP is dying” a myth? Because the predictions don’t track reality. The “PHP is dying” narrative has been continuous since at least 2004 (Slashdot discussions) through 2007 (early blog posts) to 2011 (mainstream tech press) to today.

Survivor bias works both ways. Critics remember the terrible PHP 4 code they encountered. They don’t see the modern Symfony applications with strict typing, 100% test coverage, and clean architecture. Those applications just work quietly in production.

The hype cycle favors new things. Node.js was “killing PHP” in 2012. Go was killing it in 2015. Rust in 2018. Each new language gets breathless coverage. PHP keeps shipping features and growing its ecosystem without the same fanfare.

Engagement farming.…

Continue reading on fsck.sh →

Meet Doppar: Laravel's Leaner, Faster Cousin

2026-01-28T00:00:00Z

Or: What happens when “fast enough” isn’t

318 requests per second. 1,000 concurrent users. Zero dropped connections.

Those are stress test results from Doppar, a PHP framework you probably haven’t heard of. Laravel optimizes for developer experience. Symfony optimizes for enterprise stability. Doppar optimizes for raw speed — and lets you handle the rest.

Who this is for: You’ve profiled your PHP application, optimized your queries, added caching, and still need more throughput. You’re comfortable writing integrations that would be a composer require elsewhere. You want Laravel-like syntax without Laravel-like overhead.

What Is Doppar?

Doppar is a high-performance, minimalist PHP framework that launched version 3.x in late 2025. It’s built on three principles:

Zero external dependencies for core features
Intelligent memoization of repeated executions
Attribute-first configuration

composer create-project doppar/doppar my-app cd my-app php pool server:start

Your first route:

// app/Http/Controllers/HelloController.php #[Mapper(prefix: 'api')] class HelloController extends Controller {  #[Route(uri: 'hello/{name}', methods: ['GET'])]  public function greet(string $name): Response  {  return response()->json(['message' => "Hello, {$name}!"]);  } }

Requirements: PHP 8.3+ and Composer.

History & Philosophy

Doppar was created by techmahedy, a developer who wanted Laravel’s elegant syntax without the overhead. The 3.x release in late 2025 marked its transition from experiment to usable framework. It draws a parallel to Laravel’s own origin story — Symfony existed and was robust, yet Laravel found its voice by offering something different.

The philosophy is simple:

“Need a feature? Install and use it. Don’t need it? Keep your application as simple and clean as possible.”

Doppar isn’t trying to replace Laravel or Symfony. It’s an alternative for developers who’ve squeezed every optimization out of their current stack and still need more.

Why Is It Fast?

Three techniques make Doppar faster than typical PHP frameworks:

1. Intelligent Memoization

Repeated executions are cached automatically. Configuration parsing, service resolution, route matching — anything that runs more than once gets memoized without manual intervention.

2. Zero-Dependency Core

The ORM, validation, WebSocket server, and scheduler are built into the core.…

Continue reading on fsck.sh →

Spooky Action at a Distance: When Fixing Your Proxy Breaks Your Application

2026-01-21T00:00:00Z

Or: How I Learned That “Working” and “Correct” Are Not the Same Thing

“Spooky action at a distance” (spukhafte Fernwirkung) is what Einstein called quantum entanglement in 1947—the phenomenon where measuring one particle instantly affects another, no matter how far apart they are. He meant it dismissively; the idea seemed absurd.

I first heard the term applied to software almost ten years ago, in Marco Pivetta’s (@ocramius) talk Extremely Defensive PHP. The concept stuck with me: code in one place mysteriously affecting code somewhere else, with no visible connection.

This is a story about that kind of bug.

“The ranking calculations aren’t running.”

The System: A Callback-Based Pipeline

Our ranking tool queries a third-party API for search engine data. The pipeline looks simple enough:

flowchart LR A[Send Task
Command] --> B[External
API] B --> C[Process
Command] C --> D[Calculate
Results]

Each task moves through a state machine tracked by three flags:

class AnalysisTask {  private bool $submitted = false; // Sent to external API?  private bool $completed = false; // API finished processing?  private bool $processed = false; // We fetched the results? }

The critical handoff happens via a webhook callback: when the external API finishes processing, it sends an HTTP request to our callback endpoint, which sets completed = true.

Simple, right?

The Bug: Tasks Stuck Forever

Tasks were being created and submitted successfully. The external API was processing them (we verified via their dashboard). But our process command found nothing to do. They stopped processing mid November 2025.

I pulled up the processing logic:

protected function execute(InputInterface $input, OutputInterface $output): int {  $tasksToProcess = $this->repository->findBy([  'submitted' => true,  'completed' => false, // <-- Hmm...  'processed' => false,  ]);   foreach ($tasksToProcess as $task) {  $this->processTask($task);  }   return Command::SUCCESS; }

Wait. We’re looking for tasks where completed = false?

If the callback sets completed = true when the API finishes… why would we query for tasks that haven’t completed?

The Assumption Trap

I checked the callback controller:

#[Route(…

Continue reading on fsck.sh →

Setting Up HP iLO Hardware Monitoring with OMD Labs

2026-01-13T00:00:00Z

Seven problems. That’s how many obstacles I counted before hardware monitoring for three HP ProLiant servers was finally working. The documentation made it sound so simple: enable SNMP, run check_hpasm, done.

Or: How I learned that “community project” sometimes means “bring your own band-aids”

If you’re facing a similar setup – HP ProLiant servers monitored via iLO, OMD Labs as your monitoring system – this walkthrough will save you considerable frustration.

The Setup

Three HP ProLiant DL360p Gen8 servers running VMware ESXi 7.0.3. Each server has an iLO4 management controller with its own network interface:

Server	ESXi IP	iLO IP
esxi-01	192.168.20.x	192.168.21.101
esxi-02	192.168.20.x	192.168.21.102
esxi-03	192.168.20.x	192.168.21.103

Goal: Comprehensive hardware monitoring – fans, temperatures, power supplies, RAM, RAID – via the iLO interface.

Monitoring System: OMD Labs 5.60 (ConSol Edition) with Naemon as the core and PNP4Nagios for graphing.

Sounds straightforward? It wasn’t.

Problem 1: “Failed to create new file: invalid path”

The very first attempt to create a host through the Thruk web interface greeted me with an error:

Failed to create new file: invalid path

What happened? The directory for configuration files simply didn’t exist. OMD Labs is a community project – some basic functionality isn’t perfectly configured out of the box.

The solution:

su - monitoring # As OMD site user mkdir -p ~/etc/naemon/conf.d/hosts mkdir -p ~/etc/naemon/conf.d/services mkdir -p ~/etc/naemon/conf.d/commands

Lesson learned: For production setups, it’s better to create configurations directly via CLI. The web interface is nice for quick wins but not always reliable.

The ESXi SNMP Detour

Before tackling iLO, we first tried monitoring ESXi itself via SNMP.

Enabling SNMP on ESXi

Via SSH to the ESXi host:

esxcli system snmp set --communities public esxcli system snmp set --enable true esxcli network firewall ruleset set --ruleset-id snmp --enabled true

Problem 2: SNMP MIBs Not Loaded

First test:

snmpwalk -v2c -c public esxi-01.example.com sysDescr

Result:

sysDescr: Unknown Object Identifier (Sub-id not found: (top) -> sysDescr)

The SNMP MIBs weren’t loaded on the OMD server. No big deal – numeric OIDs are more universal anyway:

snmpwalk -v2c -c public esxi-01.example.com .1.3.6.1.2.1.1.1.0

Result:

iso.3.6.1.2.1.1.1.0 = STRING: "VMware ESXi 7.0.3 build-24411414 VMware, Inc. x86_64"

Lesson learned: Always…

Continue reading on fsck.sh →

PHPStan Level 9: The Path to Bug-Free PHP

2025-12-26T00:00:00Z

Three days. That’s how long I spent debugging a payment reconciliation bug that PHPStan would have caught in three seconds.

Or: How I Learned to Stop Worrying and Love the Type System

The bug was subtle. Our API wrapper returned null during maintenance windows, but only for certain transaction types. Our tests used mocks that never returned null. Code review focused on the calculation logic, not the null-safety. Production? Production crashed at 3 AM on a Sunday.

PHPStan Level 9 would have screamed at us: “Parameter #2 $bankData of function reconcileTransaction() expects BankData, BankData|null given.”

That 3 AM incident changed how I think about type safety. Today, I’m going to show you how we eliminated 90% of our type-related bugs without writing a single additional test. The secret? Your compiler is smarter than your tests.

Why Static Analysis Changes Everything

Remember the last time you saw this in production?

Fatal error: Uncaught Error: Call to a member function format() on null in /var/www/app/PaymentProcessor.php:142

This happens because PHP is dynamically typed. Variables can be anything at runtime. Your IDE might warn you, your tests might catch 80% of cases, but that 20% finds its way to production at the worst possible time.

Static analysis tools like PHPStan analyze your code without running it. They build a complete type graph of your application and tell you exactly where things will break before you deploy.

Traditional Testing:

Write code
Write tests
Run tests
Deploy
Fix production bugs you didn’t test for

Static Analysis:

Write code
Run PHPStan
Fix type errors
Deploy with confidence
Sleep through the night

The PHPStan Level Journey (0-9)

PHPStan offers 10 levels of strictness, from “barely checking anything” to “your code is mathematically proven to not have type errors.” Each level catches progressively more subtle bugs.

Level 0: Basic Existence Checks

The gentlest introduction. PHPStan verifies that classes, functions, and methods you call actually exist.

// Level 0 catches this $user = new UserrModel(); // Typo in class name $user->getName(); // Class doesn't exist, method doesn't exist  // Level 0 allows this (but shouldn't) function process($data) {  return $data->value…

Continue reading on fsck.sh →

Async PHP in Production: Fibers, ReactPHP, and Swoole Demystified

2025-12-19T00:00:00Z

Async PHP in Production: Fibers, ReactPHP, and Swoole Demystified

PHP can handle 10,000 concurrent connections. Here’s how.

PHP’s least understood superpower

Three days. That’s how long I spent optimizing an API aggregation service that called 15 external APIs sequentially. The response time? A painful 2.1 seconds on average. Then I discovered async PHP, and that same service now responds in 520 milliseconds. That’s a 304% improvement without touching the business logic.

If you still think PHP is that slow, blocking, synchronous language from the LAMP stack era, you’re in for a surprise. In 2025, async PHP is no longer the exception. With Fibers in core since PHP 8.1, plus mature ecosystems like ReactPHP, Swoole, and Amp, PHP can drive low-latency APIs, WebSockets, and streaming pipelines without turning your codebase into callback hell.

Let me show you how async PHP works in production, when to use each approach, and how to avoid the pitfalls that will bite you at 3 AM.

The PHP Performance Revolution Nobody Talks About

Remember when handling concurrent operations in PHP meant either spinning up multiple processes (memory nightmare) or using threads (complexity nightmare)? Those days are over.

Here’s what async PHP can do today:

Process 200 RSS feeds in 2.3 seconds instead of 111 seconds (463% improvement)
Scrape 500+ web pages in the time it used to take to process 100
Handle 10x more concurrent users while maintaining consistent response times
Run WebSocket servers that keep thousands of connections alive simultaneously

The secret? Cooperative multitasking through Fibers and event loops. Let’s break down what that actually means.

Understanding PHP Fibers: The Foundation

PHP 8.1 introduced Fibers as full-stack, interruptible functions. Think of them as lightweight threads that you can pause and resume at will, but without the complexity of true parallelism.

Here’s the crucial difference: Fibers are about concurrency, not parallelism. You’re not running multiple CPU-bound tasks simultaneously. You’re efficiently juggling multiple I/O-bound operations while one waits, another runs.

Your First Fiber: The “Aha” Moment

<?php  $fiber = new Fiber(function (): string {  echo "Fiber started\n";   // Suspend execution and return control  $…

Continue reading on fsck.sh →

Laravel vs Symfony 2025: When to Use Which

2025-12-12T00:00:00Z

Laravel vs Symfony 2025: When to Use Which

A pragmatic guide for choosing the right tool - because tribal wars don’t ship products

The framework war is over. Laravel won the popularity contest. Symfony won the enterprise battle. And here’s the plot twist: it doesn’t matter.

What matters is choosing the right tool for your specific project. I’ve spent the last six months migrating a Laravel monolith to Symfony components, and another three months building a greenfield SaaS in Laravel. Both decisions were correct. Both would have been disasters if reversed.

Let me show you the decision framework I wish I’d had two years ago.

The State of PHP Frameworks in 2025

Before we dive into philosophy and code, let’s look at the hard data from JetBrains’ State of PHP 2025 survey:

Laravel: 64% market share (1,720 PHP developers surveyed)
Symfony: 23% market share
WordPress: 25% (yes, higher than Symfony, but it’s a CMS, not a framework)
Others: CodeIgniter, Yii, CakePHP combined under 10%

Here’s what nobody tells you: Laravel runs on Symfony components. Check your vendor directory in any Laravel project - you’ll find symfony/http-foundation, symfony/routing, symfony/console, and about a dozen more.

Laravel is Symfony with a gorgeous developer experience layer on top. Symfony is a collection of decoupled components that can power anything from a CLI tool to Laravel itself.

The Philosophy Gap

Laravel: Developer Happiness First

Laravel’s philosophy is radical simplicity combined with aesthetic pleasure. Taylor Otwell designed Laravel for developers who want to ship fast and enjoy the process.

// Laravel Eloquent - this just feels nice to write $activeUsers = User::where('status', 'active')  ->with('posts')  ->latest()  ->paginate(15);  return view('users.index', compact('activeUsers'));

Everything about Laravel screams “get out of your way”. Convention over configuration. Batteries included. Opinionated defaults that work for 80% of use cases.

Symfony: Flexibility and Control

Symfony’s philosophy is professional-grade flexibility. Fabien Potencier built Symfony for teams who need precise control over…

Continue reading on fsck.sh →

Symfony AssetMapper: Goodbye Webpack, Hello Simplicity

2025-12-05T00:00:00Z

What if your frontend build process was just… nothing?

The return to simplicity in frontend development

I’ve spent the last five years maintaining webpack configurations. Five years of npm install taking three minutes. Five years of debugging why my build suddenly broke after updating a single package. Five years of explaining to junior developers why they need to learn an entirely separate ecosystem just to add a JavaScript file to a Symfony project.

Then Symfony 6.3 dropped AssetMapper, and I realized we’d been solving the wrong problem all along.

The promise is almost too good to be true: Write modern JavaScript and CSS with zero build system. No Node.js, no npm, no webpack, no configuration files, no transpilation pipeline. Just PHP and the native features browsers have supported for years.

I was skeptical. You should be too. But after migrating three production applications, I’m convinced this is the future of Symfony frontend development.

The Problem We Created for Ourselves

Let me paint a familiar picture. You start a new Symfony project:

symfony new my-project --webapp

In the “old days” (like… 2023), you’d immediately run:

composer require symfony/webpack-encore-bundle npm install

And then you’d need to:

Install Node.js (specific version, of course)
Configure webpack.config.js
Set up your package.json
Deal with node_modules (hello, 400MB)
Configure Babel for transpilation
Set up watching in development
Configure build for production
Explain to your ops team why your Docker image is now 2GB

For what? To use import statements in JavaScript. Features that browsers have supported natively since 2017.

The Webpack Rabbit Hole

Here’s what a typical Encore setup looked like:

// webpack.config.js const Encore = require("@symfony/webpack-encore");  Encore.setOutputPath("public/build/")  .setPublicPath("/build")  .addEntry("app", "./assets/app.js")  .splitEntryChunks()  .enableSingleRuntimeChunk()  .cleanupOutputBeforeBuild()  .enableBuildNotifications()  .enableSourceMaps(!Encore.isProduction())  .enableVersioning(Encore.isProduction())  .configureBabel((config) => {  config.plugins.push("@babel/plugin-proposal-class-properties");  })  .configureBabelPresetEnv((config) => {  config.useBuiltIns = "usage";  config.corejs = 3;  })  .enableSassLoader()  .enablePostCssLoader()  .autoProvidejQuery();  module.exports = Encore.…

Continue reading on fsck.sh →