🐥 YellowDuck.be

🐥 Passing Structs with a Rust NIF in Elixir

2026-11-10T18:00:00Z

When using Rust NIFs in Elixir via the Rustler crate, it's often useful to pass structured data, not just integers and strings. This post shows how to pass an Elixir struct to Rust, manipulate it, and return a new struct to Elixir.

Define a struct in Elixir

Start by creating a simple struct, such as User:

defmodule MyNif.User do
  defstruct [:name, :age]
end

Define the same struct in Rust

In your NIF crate (native/my_nif/src/lib.rs), define a matching Rust struct using Rustler's NifStruct derive macro:

use rustler::NifStruct;

#[derive(NifStruct)]
#[module = "MyNif.User"]
struct User {
    name: String,
    age: u32,
}

The #[module = "MyNif.User"] attribute tells Rustler how to map the Elixir struct to the Rust struct.

Write a NIF function that uses the struct

Here's a Rust NIF that increases a user's age:

#[rustler::nif]
fn birthday(user: User) -> User {
    User {
        age: user.age + 1,
        ..user
    }
}

rustler::init!("Elixir.MyNif");

Wire it up in Elixir

In your wrapper module:

defmodule MyNif do
  use Rustler, otp_app: :my_nif_app, crate: "my_nif"

  def birthday(_user), do: :erlang.nif_error(:nif_not_loaded)
end

Call it from IEx

$ iex -S mix
iex> user = %MyNif.User{name: "Alice", age: 29}
iex> MyNif.birthday(user)
%MyNif.User{name: "Alice", age: 30}

Notes

Fields must match exactly between Elixir and Rust.
Rustler will raise a badarg error if field names or types don't match.
NifStruct automatically handles encoding and decoding using serde.

#rust #elixir

🐥 Creating a Simple Elixir NIF Using Rust

2026-11-08T18:00:00Z

Elixir is great for many things, but sometimes you need raw speed or access to native libraries. That’s where Native Implemented Functions (NIFs) come in. This post walks through creating a simple Elixir NIF using Rust with the help of the rustler crate.

Set up your Elixir project

Start with a basic Elixir application:

mix new my_nif_app
cd my_nif_app

Add :rustler as a dependency in mix.exs:

defp deps do
  [
    {:rustler, "~> 0.38.0"}
  ]
end

Fetch the dependencies:

mix deps.get

Generate the Rust NIF scaffold

$ mix rustler.new
This is the name of the Elixir module the NIF module will be registered to.
Module name > MyNif
This is the name used for the generated Rust crate. The default is most likely fine.
Library name (mynif) > my_nif
Fetched latest rustler crate version: 0.39.0
* creating native/my_nif/README.md
* creating native/my_nif/Cargo.toml
* creating native/my_nif/src/lib.rs
* creating Cargo.toml
Updating .gitignore file

Ready to go! See native/my_nif/README.md for further instructions.

This command will:

Create a native/ directory
Scaffold a Rust crate
Link it into your Elixir project

Choose a crate name when prompted, such as my_nif.

Write a simple NIF in Rust

Open the generated native/my_nif/src/lib.rs file and replace its contents with:

#[rustler::nif]
fn add(a: i64, b: i64) -> i64 {
    a + b
}

rustler::init!("Elixir.MyNif");

This defines a basic add/2 function exposed to Elixir.

Define the Elixir wrapper

In lib/my_nif.ex, wire up the NIF:

defmodule MyNif do
  use Rustler, otp_app: :my_nif_app, crate: "my_nif"

  # Fallback when the NIF is not loaded
  def add(_a, _b), do: :erlang.nif_error(:nif_not_loaded)
end

Build and test

Compile the NIF:

mix compile

Then try it out in iex:

$ iex -S mix
iex> MyNif.add(2, 3)
5

You've created a simple Elixir NIF using Rust. This lets you use Rust's performance and ecosystem while retaining Elixir's productivity.

#rust #elixir

🐥 Giving a Laravel Artisan Command an Alias

2026-11-06T18:00:00Z

Sooner or later, every codebase has a command whose name you can't remember. Say you have reports:generate-monthly. Half the team types reports:monthly from muscle memory and gets "Command not defined". You don't want to rename the command because runbooks, scripts, and Slack history all reference the old name. So you give it a second name.

The short version

Aliases are a Symfony Console feature, and Artisan is built on Symfony Console. Laravel supports them in three ways.

1. The `$aliases` property

class GenerateMonthlyReportCommand extends Command
{
    protected $signature = 'reports:generate-monthly {reportId}';

    protected $description = 'Generates the monthly report for the given id';

    protected $aliases = ['reports:monthly'];
}

Laravel's Command constructor reads this property and calls Symfony's setAliases() for you. This is the approach we use.

2. The `#[Aliases]` attribute

Laravel 13 also has class attributes for command metadata:

use Illuminate\Console\Attributes\Aliases;

#[Aliases(['reports:monthly'])]
class GenerateMonthlyReportCommand extends Command
{
    // ...
}

The #[Signature] attribute also accepts an aliases argument, so the signature and its aliases can sit together. Use whichever style your commands already use.

3. Overriding `configure()`

protected function configure(): void
{
    parent::configure();

    $this->setAliases(['reports:monthly']);
}

This works on any Laravel version because it uses plain Symfony. On recent versions, you rarely need it.

What you get

Both names run the same command with the same arguments and options:

php artisan reports:generate-monthly 123
php artisan reports:monthly 123

php artisan list shows the alias as its own entry and marks the canonical command with the alias in brackets, so people can see that the two names belong together:

reports:monthly            Generates the monthly report for the given id
reports:generate-monthly   [reports:monthly] Generates the monthly report for the given id

Gotchas

An alias is only a name. Don't put arguments or options in it. The signature ({reportId}) belongs to the command and is shared by every name. If you write 'reports:monthly {reportId}' as an alias, Symfony takes the whole string as the name, including the placeholder.
Aliases must be unique. Run php artisan list after adding one to check that it doesn't collide with another command.
Scheduling and queues. Schedule::command('reports:monthly'), $this->call(), and Artisan::call() all resolve aliases. Still, use the canonical name in code so a grep for the command finds every use.
Decide which name is canonical. The alias is a convenience. If you want people to move to the new name, make it the $signature name and keep the old one as the alias. That gives you a painless rename.
Test it. Run the command through its alias once in a test so a typo in the alias doesn't go unnoticed.

#laravel #php #tools

🐥 rsync backups that respect your .gitignore

2026-11-03T18:00:00Z

A naive rsync backup copies everything — including the megabytes of compiled assets, cached responses, and third-party dependencies you never actually need to restore. Here is how to make rsync smarter, without maintaining a separate exclude list.

The problem with a bare rsync

The simplest backup command looks like this:

rsync --delete -avh /src/ /dst/

It works, but it faithfully copies node_modules/ (often hundreds of megabytes), compiled caches, vendor trees, and log files that rotate anyway. These are not worth transferring, not worth storing, and not worth restoring.

Explicit excludes for the obvious offenders

The first fix is straightforward: pass --exclude flags for the directories you know you never want.

rsync --delete -avh \
  --exclude='logs/' \
  --exclude='node_modules/' \
  --exclude='vendor/' \
  --exclude='cache/' \
  /src/ /dst/

The trailing slash on each pattern matters: it matches directories specifically, not files that happen to share the name.

Honouring .gitignore automatically

The more interesting problem is everything your .gitignore already documents but rsync doesn't know about. Build outputs, compiled assets, secrets files — you've already told git to ignore them. Telling rsync separately is just duplication.

rsync has a --filter option that solves this cleanly:

# ':- .gitignore' means: merge each .gitignore as an exclude list
rsync --delete -avh \
  --filter=':- .gitignore' \
  --exclude='logs/' \
  --exclude='node_modules/' \
  --exclude='vendor/' \
  --exclude='cache/' \
  /src/ /dst/

The :- .gitignore rule is a dir-merge filter. As rsync descends into each directory, it reads that directory's .gitignore and applies its patterns as excludes — recursively, the same way git itself does.

Note: The --filter flag reads the contents of .gitignore files, not the .git/ directory itself. Git's implicit exclusion of .git/ is not part of any .gitignore, so those folders are included in the backup. Add --exclude='.git/' if you want to omit them.

Why keep the explicit excludes too?

node_modules/ and friends are almost always in .gitignore already, so in practice the explicit flags are redundant for most projects. But they act as a safety net: if you're backing up a directory that has no .gitignore, or an older project where someone forgot to gitignore the vendor folder, the explicit rules still fire. Belt and braces.

When --delete can't clean up after itself

Once you add --filter=':- .gitignore', you may see a warning like this:

rsync: not empty, cannot delete: ./some-project/.git
rsync: not empty, cannot delete: ./some-project

This happens when rsync's --delete flag tries to remove a directory from the destination that no longer exists (or is now excluded) on the source — but can't fully empty it first. The cause is the exclude rules themselves: rsync won't touch files it has been told to skip, so if a directory contains excluded files, rsync leaves those in place, and then can't remove the non-empty parent.

The fix is --delete-excluded, which tells rsync to also delete destination files that match an exclude rule:

rsync --delete --delete-excluded -avh \
  --filter=':- .gitignore' \
  --exclude='logs/' \
  --exclude='node_modules/' \
  --exclude='vendor/' \
  --exclude='cache/' \
  /src/ /dst/

Worth knowing: --delete-excluded cuts both ways. If you add a pattern to a .gitignore after a directory has already been backed up, the next run will remove those files from the destination too. For a mirror backup that should faithfully reflect the source, that is exactly the right behaviour — but it is worth being aware of.

The final script

#!/bin/bash

rsync --delete --delete-excluded -avh \
  --filter=':- .gitignore' \
  --exclude='logs/' \
  --exclude='node_modules/' \
  --exclude='vendor/' \
  --exclude='cache/' \
  "/path/to/source/" \
  "/path/to/destination/"

Two lines of flags, one principle: let the projects describe what's ignorable, and make the backup command listen.

#tools #best-practice #devops #git #linux

🐥 ini_set('memory_limit') Now Throws in PHP 8.5

2026-10-29T18:00:00Z

TL;DR: PHP 8.5 changed ini_set('memory_limit', ...) to throw an ErrorException when the requested value exceeds max_memory_limit. Previously it silently capped. The fix is either to lower your requested limit, configure max_memory_limit at the server level, or suppress the error when the cap is acceptable.

What happened

We upgraded a Laravel application to PHP 8.5 and a long-running Artisan import command immediately started failing with a cryptic error:

ErrorException: Failed to set memory_limit to 4294967296 bytes.
Setting to max_memory_limit instead (currently: 536870912 bytes)
  File "app/Console/Commands/ImportDataCommand.php", line 12
    ini_set('memory_limit', '4096M');

The command was requesting 4 GB of memory. The server's hard ceiling (max_memory_limit) is 512 MB. On PHP 8.4 that call silently set the limit to 512 MB and kept going. On PHP 8.5 it throws.

The PHP 8.5 change

PHP has two memory-related INI settings:

memory_limit — The per-request limit a script can raise or lower at runtime via ini_set(). Typically set in php.ini or a per-vhost config.
max_memory_limit — A hard ceiling added in PHP 8.5. Only changeable at the system level (php.ini, not at runtime). Scripts cannot exceed it.

Before 8.5, setting memory_limit above the OS-level ceiling either worked (no hard enforcement) or was silently clamped. PHP 8.5 introduced max_memory_limit as a formal concept and made the runtime enforce it with an error — because silently ignoring the requested value is surprising and hard to debug.

Note: This is a silent-to-loud change. Code that appeared to work fine on 8.4 — because the limit was quietly capped — will now throw on 8.5 if the cap is exceeded.

The three real fixes

1. Raise `max_memory_limit` on the server (correct, if you own the server)

If the command genuinely needs 4 GB, the honest fix is to grant it at the system level. Add this to your php.ini or CLI php.ini:

max_memory_limit = 4096M
memory_limit     = 4096M

Then remove the ini_set from the command entirely. Runtime limits belong in configuration, not in application code.

2. Pass the limit via the CLI (good for scheduled commands)

If you run the command from a scheduler or cron, set the limit as a CLI flag rather than from inside the script:

php -d memory_limit=4096M artisan import:data

This keeps the application code clean and makes the resource budget visible at the call site — right where your ops team or scheduler can see and change it.

3. Suppress the error and accept the cap (quick, pragmatic)

If the command works fine within the system's 512 MB ceiling, suppress the error with @:

// Requests 4096M, silently accepts the max if lower
@ini_set('memory_limit', '4096M');

Warning: Only use this if you are genuinely okay with whatever the server's ceiling is. If the command actually needs 4 GB and only gets 512 MB, you have suppressed a real warning and set yourself up for an OOM crash later.

4. Use `-1` (unlimited)

Passing -1 removes the PHP-level cap entirely and relies on the OS to manage memory. This does not trigger the max_memory_limit check:

ini_set('memory_limit', '-1');

Warning: Unlimited memory is a footgun on shared hosts or containers with soft limits. Use it only for trusted CLI commands on dedicated infrastructure.

What we did

The command runs as a scheduled job on a dedicated server. We moved the memory configuration out of the PHP script and into the cron invocation:

# Scheduler entry (before)
php artisan import:data

# Scheduler entry (after)
php -d memory_limit=4096M artisan import:data

And removed the ini_set from the command's handle() method entirely. The command no longer makes assumptions about its own resource budget — that's the scheduler's job.

How to find this in your own codebase

Before upgrading to PHP 8.5, grep your codebase for runtime memory overrides:

grep -rn "ini_set.*memory_limit" app/ bootstrap/

Any hit that requests more than your server's max_memory_limit will throw. Check what your server's ceiling is with:

php -r "echo ini_get('max_memory_limit');"

If that returns empty or -1, no ceiling is currently configured and you are fine until an admin adds one.

The PHP 8.5 release notes cover this change under the INI settings section. The RFC that introduced max_memory_limit is wiki.php.net/rfc/max_memory_limit.

#development #laravel #php

🐥 Smarter PR Size Labels with Weighted Scoring

2026-10-27T18:00:00Z

At work, we do a lot of code review. Like most teams, we've learned the hard way that a 1,500-line PR is not the same as a 500-line PR—even if the diff viewer disagrees.

We've been running a GitHub Actions workflow that automatically labels every pull request with a size badge: small, medium, or large. Recently, we overhauled it, and the improvements are worth sharing.

Why bother labelling PR size?

A size label on a PR does one simple thing: it sets expectations before anyone opens the diff.

A reviewer who sees small knows they can knock it out between two meetings. Someone who sees large knows to carve out an hour and bring coffee. And if the whole team can see the size distribution in the pull request list at a glance, they can prioritise review queues more effectively and spot when a feature branch is growing out of hand before it becomes a problem.

It also creates a gentle forcing function for authors. When you know the workflow is going to slap a large on your PR, you think twice about whether those refactors really need to live in the same commit.

The naive approach and its problems

The first version of our workflow was simple: count additions, count deletions, and compare the total to a threshold.

score = additions + deletions

That works, but it has some obvious blind spots:

Deleting code is easy to review. A file removal or a big git rm shouldn't count the same as a 200-line feature addition. The reviewer isn't absorbing new logic; they're confirming that something is gone.
Test files are verbose by design. A well-tested change might add 300 lines of test code alongside 80 lines of feature code. Penalising it the same as 380 lines of business logic discourages good testing habits.
Some PRs are simply not reviewable. Our old workflow topped out at large regardless of score. A 5,000-line PR got the same label as a 700-line one, which gave reviewers no signal that they were looking at something that genuinely needed to be split.

The weighted scoring model

Our new approach scores each file individually, with different weights depending on the type of change.

Three file categories

Deleted files (status === 'removed'): the entire file is going away. There's almost no cognitive load for a reviewer—they need to confirm the deletion is intentional and check for stray references. We weight the lines at 20% and add a flat 10 to the score per file.

score += (f.additions + f.deletions) * 0.2 + 10;

Test files: identified by a set of patterns covering the conventions we actually use (*Test.php, *Tests.php, *.spec.ts, *.test.ts, and paths under tests/ or test/). These are important, but they're also repetitive—a reviewer can skim a block of assertions much faster than an equivalent block of business logic. Additions are weighted at 50%, deletions at 15%, and each test file adds 10 to the flat score.

score += f.additions * 0.5 + f.deletions * 0.15 + 10;

Everything else: regular source files count additions at full weight, deletions at 30%, and each file adds 20 to the flat score. The per-file component matters because touching ten files in different parts of the system—even with few lines changed—still takes real review time to understand the blast radius.

score += f.additions + f.deletions * 0.3 + 20;

Thresholds

Once we have the weighted score, we bucket it:

Label	Score
`small`	≤ 250
`medium`	≤ 900
`large`	≤ 1800
`not-reviewable`	> 1800

We deliberately raised the thresholds compared to our first version. The old numbers were too aggressive—a well-structured change with a handful of files and some tests would land in medium even when it was genuinely easy to review. The new thresholds better reflect the actual reviewer experience.

The `not-reviewable` label

This is new, and it's probably the most useful addition. When a PR scores above 1,800, it gets labelled not-reviewable. That's a signal to the author—not a judgment, just a fact—that the PR is too large to give a meaningful review.

It's also a signal to reviewers that they're not expected to wade through it; the author needs to split it first.

The label swaps in and out cleanly alongside the others: if a PR starts as not-reviewable, gets split, and the score drops, the next push removes the label and applies the correct one.

Ignoring noise

The workflow reads a .github/pr-size-ignore.txt file where you can list glob patterns for files that should be excluded entirely from scoring. Ours includes things like lock files, generated assets, and vendored code. There's no point penalising a PR because Composer updated a JSON file.

# .github/pr-size-ignore.txt
composer.lock
package-lock.json
*.min.js
public/build/**

The full workflow

The workflow triggers on pull_request_target (opened, synchronised, or reopened), skips Dependabot PRs, and needs pull-requests: write and issues: write permissions to manage labels.

It paginates through the file list (GitHub caps the API at 3,000 files), filters out ignored paths, scores each file with the logic above, determines the label, removes any stale size label, and applies the new one. The whole thing runs in a single actions/github-script step with no external action dependencies beyond actions/checkout.

The label swap is idempotent: if the correct label is already on the PR, no API call is made.

Full workflow source

name: PR Size Label

on:
  pull_request_target:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write
  issues: write

jobs:
  label:
    runs-on: ubuntu-latest
    if: github.actor != 'dependabot[bot]'

    steps:
      - uses: actions/checkout@v4

      - name: Apply size label
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const path = require('path');

            // Read ignore patterns from .github/pr-size-ignore.txt
            const ignoreFile = '.github/pr-size-ignore.txt';
            const ignorePatterns = fs.existsSync(ignoreFile)
              ? fs.readFileSync(ignoreFile, 'utf8')
                  .split('\n')
                  .map(l => l.trim())
                  .filter(l => l && !l.startsWith('#'))
              : [];

            function globToRegex(pattern) {
              let result = '';
              for (let i = 0; i < pattern.length; i++) {
                const c = pattern[i];
                if (c === '*' && pattern[i + 1] === '*') {
                  result += '.*';
                  i++;
                  if (pattern[i + 1] === '/') i++;
                } else if (c === '*') {
                  result += '[^/]*';
                } else if (c === '?') {
                  result += '[^/]';
                } else if (['.', '+', '^', '$', '{', '}', '(', ')', '|', '[', ']', '\\'].includes(c)) {
                  result += '\\' + c;
                } else {
                  result += c;
                }
              }
              return new RegExp('^' + result + '$');
            }

            function isIgnored(filePath, patterns) {
              return patterns.some(pattern => {
                const regex = globToRegex(pattern);
                // Patterns without a slash match against the basename as well
                if (!pattern.includes('/') && !pattern.startsWith('**/')) {
                  return regex.test(filePath) || regex.test(path.basename(filePath));
                }
                return regex.test(filePath);
              });
            }

            // Fetch all changed files (paginated, GitHub caps at 3 000)
            const allFiles = [];
            for (let page = 1; ; page++) {
              const { data: batch } = await github.rest.pulls.listFiles({
                owner: context.repo.owner,
                repo: context.repo.repo,
                pull_number: context.issue.number,
                per_page: 100,
                page,
              });
              allFiles.push(...batch);
              if (batch.length < 100) break;
            }

            const relevant = allFiles.filter(f => !isIgnored(f.filename, ignorePatterns));

            function isTestFile(filePath) {
              const base = path.basename(filePath);
              return (
                /Test(s)?\.php$/.test(base) ||
                /\.(spec|test)\.(ts|js|tsx|jsx)$/.test(base) ||
                /^tests\//.test(filePath) ||
                /\/tests\//.test(filePath) ||
                /\/test\//.test(filePath)
              );
            }

            // Score each file with weighted contributions:
            // - Deleted files: lines at 20 % weight, file count at 10
            // - Test files:    additions at 50 %, deletions at 15 %, file count at 10
            // - Regular files: additions at 100 %, deletions at 30 %, file count at 20
            let score = 0;
            let additions = 0, deletions = 0;
            for (const f of relevant) {
              additions += f.additions;
              deletions += f.deletions;
              if (f.status === 'removed') {
                score += (f.additions + f.deletions) * 0.2 + 10;
              } else if (isTestFile(f.filename)) {
                score += f.additions * 0.5 + f.deletions * 0.15 + 10;
              } else {
                score += f.additions + f.deletions * 0.3 + 20;
              }
            }

            const filesChanged = relevant.length;

            core.info(`Relevant files: ${filesChanged} | +${additions} -${deletions} | score: ${score.toFixed(1)}`);

            const sizeLabel = score <= 250 ? 'small'
                            : score <= 900 ? 'medium'
                            : score <= 1800 ? 'large'
                            : 'not-reviewable';

            // Swap out any existing size label
            const SIZE_LABELS = ['small', 'medium', 'large', 'not-reviewable'];
            const { data: currentLabels } = await github.rest.issues.listLabelsOnIssue({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            for (const label of currentLabels) {
              if (SIZE_LABELS.includes(label.name) && label.name !== sizeLabel) {
                await github.rest.issues.removeLabel({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  issue_number: context.issue.number,
                  name: label.name,
                });
              }
            }
            if (!currentLabels.some(l => l.name === sizeLabel)) {
              await github.rest.issues.addLabels({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                labels: [sizeLabel],
              });
            }

            core.info(`Applied label: ${sizeLabel}`);

Things to keep in mind

Create the not-reviewable label first. GitHub's label API throws if you try to apply a label that doesn't exist in the repository. Add it once through the UI or with the API before the workflow runs.

Test file detection is heuristic. The patterns we use match our conventions. If your project puts tests in a __tests__ directory or uses a .test.rb suffix, you'll need to adjust the isTestFile function.

The thresholds are starting points. What counts as small depends entirely on your team's pace and context. We tuned ours over a few weeks by looking at which PRs felt easy and which felt painful, and adjusting until the labels matched our intuition. Start with something reasonable and iterate.

PR size labels are a low-effort, high-signal addition to any review workflow. The key insight behind the weighted model is that not all lines are equal. A deleted file, a test assertion, and a new service class represent very different amounts of reviewer work. Treating them the same produces labels that mislead; treating them differently produces labels that actually help.

The workflow is about 100 lines of JavaScript inside a YAML file. It's easy to read, easy to adapt, and it has meaningfully changed how we queue and prioritise reviews at Contractify.

#javascript #development #best-practice #github #git

🐥 Debugging a 502 on a Signed Redirect: nginx's "upstream sent too big header"

2026-10-26T18:00:00Z

You've built a signed redirect endpoint. It validates a token, generates a URL, and sends the browser on its way with a 302. It works perfectly in local development but fails with a cryptic 502 Bad Gateway in staging. Here's how to diagnose and fix it without touching your web server config.

The symptom

A curl -v request to the endpoint returns nginx's own 502 page—not a Laravel or application error page, just nginx's default 150-byte HTML. That detail matters: it means PHP-FPM never delivered a response nginx could forward. The application may have produced something, but nginx rejected it before the browser ever saw it.

Finding the root cause

The nginx error log is the first place to look:

upstream sent too big header while reading response header from upstream

That single line explains everything. nginx has a default buffer for reading response headers from an upstream FastCGI process (fastcgi_buffer_size, which defaults to 4 KB). The 302 response your application returned was otherwise valid, but its Location header was too long to fit in that buffer. nginx dropped the whole response and returned a 502.

This happens frequently with e-signature providers, OAuth flows, and any service that encodes its entire state (session, return URL, signature, expiry) in a redirect URL. Those URLs routinely run to several kilobytes.

Why it only fails in staging

Local development typically uses the built-in PHP server or a framework dev server, neither of which imposes nginx's header buffer limits. The problem is invisible until nginx sits between the application and the browser—which is the case in every hosted environment but rarely in local development.

The obvious fix and why to think twice

The textbook answer is to raise nginx's buffer size:

fastcgi_buffer_size 32k;
fastcgi_buffers 16 32k;

This works, but it requires access to the server config and a reload. It also papers over the underlying issue: you're transmitting a very large URL in an HTTP header, which is inherently fragile. Different proxies, CDNs, and load balancers have their own header size limits, and you may hit another one later.

A better fix: move the URL out of the header

HTTP redirects put the destination in a Location header. If instead you put the URL in the response body, header buffer limits are irrelevant—response bodies are streamed, not buffered in header-size chunks.

The simplest implementation is a minimal HTML page with a <meta> refresh and a JavaScript fallback:

$url = $this->buildSigningUrl($signer);

return response(
    '<html><head><meta http-equiv="refresh" content="0;url=' . e($url) . '"></head>' .
    '<body><script>window.location.replace(' . json_encode($url) . ')</script></body></html>'
);

The browser executes the redirect client-side in under a frame. From the user's perspective, it's indistinguishable from a 302. From nginx's perspective, it's a normal 200 response with a small body—no oversized headers and no 502.

Why not use a URL shortener or cache indirection?

An alternative is to store the long URL behind a short token and redirect the browser to a local endpoint that looks it up:

/esign/{uuid}?redirect=1  →  /esign/forward/{token}  →  {long signing URL}

The first redirect is short and fits in nginx's buffer. But the second redirect—from your forward endpoint to the signing URL—still goes through PHP-FPM and nginx, still puts the long URL in a Location header, and still hits the same limit. You've added a round trip without solving anything.

The only indirection that works is one where the browser makes the final hop to the long URL, not your server—which is exactly what the HTML body approach does.

The diagnostic checklist

If you hit a 502 on a redirect endpoint and can't reproduce it locally:

curl -v the URL—check whether the response is an application error page or nginx's own 502 page. Nginx's own page means the problem is between nginx and upstream, not inside your application.
Check /var/log/nginx/error.log around the timestamp. upstream sent too big header points to buffer limits; connect() failed or upstream timed out point elsewhere.
Check PHP-FPM's log for crashes or OOM kills if the nginx log is silent.
Measure the URL you're redirecting to. If it's over 3–4 KB, the buffer is likely the culprit.

The pattern generalizes beyond PHP. Any application server behind nginx—Python/WSGI, Node, or Go—can trigger the same error with a large redirect. The fix is the same: put the long URL in the body, not a header.

#laravel #php #http #devops

🐥 Why PHP's Recent Critical RCEs Are an Architectural Non-Problem in Elixir

2026-10-25T18:00:00Z

The cybersecurity landscape was shaken in October 2026 by the disclosure of two critical, unauthenticated Remote Code Execution (RCE) vulnerabilities in PHP affecting versions 8.2 through 8.5. Rated at a severe CVSS v4.0 score of 9.2, these vulnerabilities allow attackers to compromise servers before any application-level security code even executes.

Whenever major security events occur in mainstream runtime environments, it is worth examining how alternative language ecosystems handle the same vectors. For teams using Elixir and the BEAM virtual machine, these specific vulnerabilities are not just avoided by careful coding—they are entirely neutralized by the runtime's underlying architecture.

Here is a deep technical breakdown of why the structural flaws exposed in PHP's 2026 advisories are a non-problem in Elixir, followed by how to safely manage memory and package security in the BEAM ecosystem.

Vulnerability 1: The OOM Partial Initialization Attack (CVE-2026-109618)

What Happened in PHP

CVE-2026-109618 (tracked via GHSA-w8hw-w9fx-j79w) describes an Out-of-Memory (OOM) corruption flaw. When a web request hits a PHP worker, the runtime allocates memory to initialize internal request data structures. If an allocation failure occurs mid-initialization, the process is interrupted, leaving the request data in a partially formed state.

During the subsequent request cleanup phase, PHP's memory management engine misinterprets this malformed, incomplete internal data as valid data structure pointers. Attackers can weaponize this behavior to hijack the pointer execution path, achieving unauthenticated Remote Code Execution.

Why It Is a Non-Problem in Elixir

The BEAM virtual machine manages memory in a completely decentralized fashion compared to traditional monolithic runtimes.

Per-Process Heaps: In Elixir, every concurrent operation (like an incoming HTTP request handled by Cowboy or Bandit in a Phoenix application) runs inside its own isolated, lightweight BEAM process. Each process contains its own private heap. There is no massive, shared global heap for request initialization.
Fail-Stop Mentality ("Let it Crash"): If an Elixir process encounters a fatal error—such as allocating memory beyond a configured limit—the runtime does not attempt a delicate, complex cleanup dance over partially initialized, untyped memory structures. The BEAM instantly kills the isolated process.
Immutability and Type Safety: Because data structures in Elixir are immutable and managed strictly by a type-safe virtual machine layer, a crash during process creation simply causes the supervision tree to discard the process ID (PID) and reclaim the isolated heap in one sweeping, atomic operation. There are no dangling initialization pointers to misinterpret.

Defensive Engineering: Monitoring BEAM Process Memory Thresholds

While an OOM error cannot corrupt the BEAM runtime state, a runaway process consuming too much memory can still starve the operating system. Elixir allows you to proactively enforce memory limits at the individual process level to safely drop abnormal requests before they impact the node.

You can set a max memory threshold dynamically for temporary request processes using Process.flag/2:

# Enforcing a 50MB memory ceiling on a specific task process
Task.Supervisor.start_child(MyTaskSupervisor, fn ->
  Process.flag(:max_heap_size, %{size: 6_250_000, kill: true, error_logger: true})

  # Process payload here...
  perform_heavy_lifting()
end)

size: Measured in machine words (1 word = 8 bytes on 64-bit systems). 6_250_000 words equals exactly 50 MB.
kill: true: Instructs the BEAM to instantly kill the process if it crosses the limit, rather than letting it slow down the node with emergency garbage collection loops.
error_logger: true: Automatically logs a descriptive crash dump so security and operations teams can audit potential memory-exhaustion attack vectors.

Vulnerability 2: Stale Worker Global State (CVE-2026-109619)

What Happened in PHP

CVE-2026-109619 (tracked via GHSA-6wmf-4rv5-p3rp) is a Use-After-Free variant tied to persistent worker state. PHP setups typically rely on persistent processes (like PHP-FPM, LiteSpeed, or Apache mod_php modules) to handle thousands of serial HTTP requests over their lifespan to avoid cold-start overhead.

In this exploit, request-specific internal state managed to persist in the worker's memory space even after its backing allocation was freed. When a subsequent, unrelated HTTP request was assigned to that exact same worker thread, the worker referenced that stale, dangling memory state before normal initialization routines could clean it. This state bleeding creates a predictable memory window for arbitrary code execution. An informational advisory (CVE-2026-115560) was later issued regarding session upload progress handlers interacting with this state.

Why It Is a Non-Problem in Elixir

This vulnerability represents a classic failure of the Shared-State Architecture. Elixir completely eradicates this entire attack vector using a Share-Nothing Architecture driven by the Actor Model.

Zero State Leakage Between Requests: When a web request reaches an Elixir web server, a completely new BEAM process is spawned. When the response is sent, that process terminates. Because memory is not shared between processes, it is physically impossible for Request B to access, inherit, or accidentally execute memory allocated by Request A.
No Mutability, No Side-Effects: A major factor in the PHP exploit is that runtime configuration and state can be mutated dynamically at request runtime. In Elixir, data is entirely immutable. You cannot mutate an underlying global memory buffer during a request lifecycle because global mutable state does not exist in the traditional sense. Even stateful storage (like an Agent or GenServer) relies on explicit message passing rather than shared pointer access.

Ecosystem Security: Managing Hex Third-Party Supply Chain Risks

While the BEAM protects you from core runtime vulnerabilities, any modern application is still susceptible to supply chain attacks via third-party libraries. PHP handles this via Composer; Elixir relies on the Hex package manager. Because the Elixir ecosystem is smaller, proactive supply chain auditing is critical.

To secure your production pipeline against malicious dependency injections or unpatched packages, incorporate these three automated layers into your Continuous Integration (CI) suite:

mix deps.unlock --check-unused: Ensures that your mix.lock file matches your configuration exactly and prevents dangling or untracked packages from sneaking into your builds.
mix hex.audit: Checks your local dependency tree against the Hex registry to find packages that have been retired by their maintainers due to security vulnerabilities or deprecation.
Sobelow (Static Analysis): Integrate Sobelow into your build process to scan Elixir code specifically for application-level vulnerability paths (like SQL injection or insecure deserialization in Phoenix applications).

# Add to your CI workflow
mix deps.unlock --check-unused
mix deps.get
mix hex.audit
mix sobelow --config .sobelow-conf --exit

Architecture as a Security Shield

The October 2026 PHP Security Advisory demonstrates that even when you write flawless application code, you remain exposed to the memory mechanics of your underlying runtime platform. PHP engineers were forced to scramble to apply emergency configurations (such as setting memory_limit=-1 or disabling session upload progress features) as brittle stopgaps while waiting for patches.

Elixir developers didn't have to change a single line of code or adjust their production topologies during this advisory cycle. By moving away from shared-memory, single-threaded worker abstractions and adopting the BEAM's immutable, process-isolated model, Elixir turns severe runtime engineering vulnerabilities into an architectural impossibility.

Architectural & Security Feature Summary

Security Risk / Feature	PHP Runtime Environment (C-Based Engine)	Elixir / BEAM Runtime Environment
Primary CVE Focus	CVE-2026-109618 & CVE-2026-109619	None (architecturally immune to these vectors)
Concurrency Model	Ephemeral request execution inside persistent, reusable worker processes.	Spawns unique, highly isolated lightweight processes for every single request.
Memory Isolation	Shared heap inside the worker process; vulnerable to pointer corruption.	Share-nothing architecture; absolute memory boundaries per process.
Handling Allocation Faults	Transitions into delicate cleanup paths that risk treating uninitialized state as valid.	Immediate process termination ("Let it crash") accompanied by atomic heap reclamation.
Process Control	Handled globally via pool managers (e.g., `php-fpm.conf`).	Granular, per-process heap caps using `Process.flag(:max_heap_size, ...)`.
Supply Chain Guardrails	Mainstream security coverage via Composer Audit.	Targeted protection via `mix hex.audit` and static application analysis with Sobelow.

#development #php #elixir #phoenix

🐥 Fixing "header_too_long" When Downloading Precompiled NIFs in Elixir

2026-10-24T17:00:00Z

If you've recently run mix compile on an Elixir project that uses precompiled NIFs, such as mdex or lumis, you may have seen an error like this:

[info] Attempt 1 failed with {:error, "couldn't fetch NIF from https://github.com/...: {:error, {:header_too_long, {:max, 10240}}}"}

== Compilation error in file lib/mdex_native/native.ex ==
** (RuntimeError) Error while downloading precompiled NIF: couldn't fetch NIF from https://github.com/...

This is frustrating because mix deps.get succeeds. The problem only appears during compilation.

What's Going On?

Elixir libraries that include native code (Rust, C, etc.) often ship precompiled binaries called NIFs (Native Implemented Functions), so you don't need a native toolchain to use them. The library rustler_precompiled handles downloading the right binary for your platform at compile time.

Under the hood, rustler_precompiled uses Mint, an Elixir HTTP client, to fetch NIF archives from GitHub Releases.

Here's the problem: GitHub's CDN now returns very large response headers on release asset redirect requests—headers that exceed Mint's default maximum of 10,240 bytes (10 KB). When Mint hits that cap, it aborts the request with {:header_too_long, {:max, 10240}}, and compilation fails.

This isn't a bug in your code. It's an upstream issue involving GitHub's infrastructure and Mint's conservative defaults.

Three Ways to Fix It

Option 1 — Download the NIF Manually with curl (Fastest)

curl doesn't have the same header size restriction. You can download the NIF archive directly and let rustler_precompiled pick it up from its cache on the next compile.

First, find the download URLs in the error message in your terminal, then fetch the archive:

curl -L -o /tmp/your_nif.tar.gz "https://github.com/.../your_nif.tar.gz"

rustler_precompiled caches NIFs in ~/.cache/rustler_precompiled/ (Linux/macOS). Copy the downloaded archive there, then rerun mix compile.

Option 2 — Update the Dependency

The maintainers of these libraries are aware of the issue. A newer release may have switched away from Mint for the download step or increased Mint's header limit. Try:

mix deps.update your_nif_package
mix compile

This is the cleanest long-term fix if a patched version is available.

Option 3 — Force Build from Source

If you have the Rust toolchain installed, you can tell rustler_precompiled to compile the NIF locally instead of downloading it.

Add this to config/dev.exs (or config/config.exs):

config :rustler_precompiled, :force_build, your_nif_package: true

And add Rustler as an optional dependency in mix.exs:

{:rustler, ">= 0.0.0", optional: true}

Then run mix deps.get && mix compile. Compilation will take longer because it builds native code, but it will work regardless of GitHub's header behavior.

Which Should You Choose?

Situation	Recommended fix
Just need to unblock right now	Option 1 (manual curl)
A patched release is available	Option 2 (update deps)
You control the environment and have Rust	Option 3 (force build)
CI/CD pipeline is broken	Option 1 or 3, depending on whether Rust is available

The Broader Lesson

This failure mode—a third-party infrastructure change silently breaking your build—is a good reminder to:

Pin your NIF dependency versions so you're not surprised by new behavior after an update.
Cache precompiled NIFs in CI so you're not downloading them on every build.
Have a fallback strategy (force build) for environments where downloading isn't reliable.

Precompiled NIFs are a major convenience for Elixir developers who don't want to manage native toolchains. But they introduce a network dependency at compile time, and as this issue shows, that dependency can break in unexpected ways.

The Proper Fix

The poeple behind rustler_precompiled are working on a proper fix. You can follow the progress with this pull request.

#development #http #elixir #terminal

🐥 Streaming ZIP downloads in Phoenix with zstream

2026-10-23T17:00:00Z

When you need to let users download multiple files as a ZIP in a Phoenix application, creating the archive upfront is often wasteful. It costs disk space, adds latency, and does not scale well for large files.

A better approach is to stream the ZIP archive directly to the browser while it's being generated. In Elixir, the zstream library makes this straightforward and production-ready.

This post shows how to stream a ZIP file from a Phoenix controller without creating temporary files.

The idea

The solution combines three pieces:

Plug.Conn.send_chunked/2 to start a streaming HTTP response
zstream to generate ZIP data incrementally
File streams (File.stream!/3) to avoid loading files into memory

The browser starts downloading immediately, while the server produces ZIP chunks on the fly.

Adding the dependency

def deps do
  [
    {:zstream, "~> 0.6"}
  ]
end

Streaming a ZIP from a controller

defmodule MyAppWeb.DownloadController do
  use MyAppWeb, :controller

  def images(conn, _params) do
    files = [
      {"image1.jpg", "/data/images/image1.jpg"},
      {"image2.png", "/data/images/image2.png"}
    ]

    conn =
      conn
      |> put_resp_header("content-type", "application/zip")
      |> put_resp_header(
        "content-disposition",
        ~s(attachment; filename="images.zip")
      )
      |> send_chunked(200)

    zip_stream =
      Zstream.zip(
        Enum.map(files, fn {name, path} ->
          Zstream.entry(name, File.stream!(path, [], 64_000))
        end)
      )

    Enum.reduce_while(zip_stream, conn, fn chunk, conn ->
      case Plug.Conn.chunk(conn, chunk) do
        {:ok, conn} -> {:cont, conn}
        {:error, :closed} -> {:halt, conn}
      end
    end)
  end
end

What's happening here:

Each file is represented as a Zstream entry
The file contents are streamed from disk
Zstream.zip/1 produces a stream of ZIP binary chunks
Each chunk is forwarded to the client using Plug.Conn.chunk/2

At no point is the full ZIP or any full file loaded into memory.

Adding folders to the ZIP

ZIP archives don't require explicit directory entries. Just use paths in the entry name:

Zstream.entry("images/image1.jpg", File.stream!(path, [], 64_000))

Why this approach works well

No temporary ZIP files
Constant memory usage
Handles large files gracefully
The download starts immediately in the browser
Works with standard reverse proxies like Nginx or Caddy

Common pitfalls

Always call send_chunked/2 before streaming data
Handle {:error, :closed} when the client disconnects
Use reasonably large chunk sizes (32–128 KB)
Ensure file paths and names are trusted to avoid ZIP path traversal

Using this from LiveView

LiveView cannot stream responses itself. The usual pattern is to trigger a navigation to the controller action:

push_navigate(socket, to: ~p"/downloads/images")

The controller then handles the streaming ZIP download as shown above.

Closing thoughts

If you need to package many files into a ZIP download in Phoenix, zstream is a simple and robust solution. It fits naturally with Plug's chunked responses and keeps resource usage predictable, even under load.

For most applications, this is the cleanest way to offer ZIP downloads without touching the filesystem at all.

#pattern #http #elixir #phoenix

🐥 8 Chunking strategies for RAG-based agents

2026-10-20T17:00:00Z

Fixed-Size: cuts text every fixed number of tokens, with a small overlap.
Recursive: splits on paragraphs first, falling back to lines then words and characters only when a piece is still too big.
Document-Based: splits wherever the document already marks a break, a heading, a chapter, an HTML tag, so a markdown file becomes one chunk per section on its own.
Semantic: embeds each sentence, checks its similarity to the one before it, and starts a new chunk when that similarity drops. This finds real topic shifts instead of guessing by length.
LLM-Based: asks an LLM to rewrite the text as standalone propositions, one idea per line, and turns each into a chunk, high quality but expensive across a large corpus.
Agentic: an AI agent reads each document, decides what it is (code, contract, table), and picks the chunking method for that file instead of one rule for everything.
Late Chunking: runs the full document through an embedding model, then applies normal split boundaries and mean-pools within each boundary to create chunk embeddings.
Hierarchical: breaks the document into layers, sections, paragraphs, then sentences

Courtesy of the ByteByteGo newsletter.

#ai #langchain

🐥 Translating country codes to full names in Elixir using `ex_cldr_countries`

2026-10-18T17:00:00Z

Unlike JavaScript's Intl.DisplayNames, Elixir doesn't provide built-in localization for country names. However, with the help of the excellent ex_cldr_countries package, you can easily achieve dynamic, localized country translations backed by official Unicode CLDR data.

Installation

Add the package to your mix.exs:

defp deps do
  [
    {:ex_cldr_countries, "~> 2.0"}
  ]
end

Then fetch it:

mix deps.get

Setting Up a Backend

Most examples online show calling Cldr.Countries.from_iso/2 directly, but modern ex_cldr usage requires a backend module. Without one, you're relying on a default backend that may not be configured — and you lose control over which locales get compiled in.

Create a backend module in your app:

# lib/my_app/cldr.ex
defmodule MyApp.Cldr do
  use Cldr,
    locales: ["en", "fr", "nl"],
    default_locale: "en",
    providers: [Cldr.Countries]
end

The locales list determines which translations get compiled into your app. Keep it to what you actually need — CLDR data is large and including everything will bloat your build.

Translating Country Codes

With the backend in place, translating a country code is straightforward:

MyApp.Cldr.Countries.from_iso(:BE, locale: "fr")
# => {:ok, "Belgique"}

MyApp.Cldr.Countries.from_iso(:NL, locale: "en")
# => {:ok, "Netherlands"}

MyApp.Cldr.Countries.from_iso(:DE, locale: "nl")
# => {:ok, "Duitsland"}

The first argument is the ISO 3166-1 Alpha-2 code as an atom (:BE, :NL, :DE, …)
The locale option sets the output language
If the translation can't be found, it returns an {:error, reason} tuple, so it's safe to pattern match on

Why This Approach

The backend module gives you three concrete benefits:

Scoped locale compilation — only the locales you list get compiled, keeping your build lean
Explicit and testable — the backend is a real module you can reference directly in tests
No global state surprises — the bare Cldr.* namespace is just a shim that delegates to whichever backend is configured as the default; using your own backend is always more predictable

For most Phoenix applications, dropping this into a lib/my_app/cldr.ex file is all the setup you need.

#development #best-practice #elixir

🐥 Handling local timezones in Ash while storing UTC datetimes

2026-10-14T17:00:00Z

When building Elixir applications with the Ash Framework, it's a best practice to store all datetimes in UTC in your database. However, users typically interact with your application in their local timezone, so you need a reliable way to convert their input into UTC—and show it back in their local time.

This post shows how to handle that conversion cleanly and reusably in Ash actions using a custom change module.

Why store in UTC?

Storing all datetimes in UTC avoids timezone ambiguity and makes it easier to compare, sort, and query times consistently—especially if your users are spread across multiple regions. PostgreSQL and Ash support UTC datetime types (:utc_datetime), and your application should convert values at the boundaries: when receiving input or displaying output.

Define UTC datetime attributes

First, define the attributes on your Ash resource using :utc_datetime:

attributes do
  attribute :starts_at, :utc_datetime
  attribute :ends_at, :utc_datetime
end

Add user-local input arguments

In your Ash action, accept user-local datetime input as strings, NaiveDateTime, or DateTime structs:

actions do
  create :schedule do
    argument :starts_at_local, :string
    argument :ends_at_local, :naive_datetime

    change {MyApp.Changes.ConvertLocalDatetimeToUtc, arg_key: :starts_at_local, field: :starts_at}
    change {MyApp.Changes.ConvertLocalDatetimeToUtc, arg_key: :ends_at_local, field: :ends_at}
  end
end

Reusable change module

Ash's change DSL expects a module implementing Ash.Resource.Change. Here's a reusable implementation you can drop into your project:

defmodule MyApp.Changes.ConvertLocalDatetimeToUtc do
  @moduledoc """
  Converts a local datetime argument (string, NaiveDateTime, or DateTime)
  to UTC and assigns it to an Ash attribute. Gracefully handles `nil` values.

  Options:
    - `:arg_key` — the action argument holding the local datetime value
    - `:field` — the resource attribute to assign the UTC value to
    - `:timezone_key` — the context key for the user's timezone (default: `:user_timezone`)
  """

  use Ash.Resource.Change

  def init(opts) do
    opts = Keyword.put_new(opts, :timezone_key, :user_timezone)
    {:ok, opts}
  end

  def change(changeset, opts, _context) do
    arg_key = opts[:arg_key]
    field = opts[:field]
    timezone_key = opts[:timezone_key]
    timezone = Ash.Changeset.get_context(changeset, timezone_key) || "UTC"

    case Ash.Changeset.fetch_argument(changeset, arg_key) do
      {:ok, nil} ->
        changeset

      {:ok, value} ->
        case do_convert_to_utc(value, timezone) do
          {:ok, utc_dt} ->
            Ash.Changeset.force_change_attribute(changeset, field, utc_dt)

          _ ->
            Ash.Changeset.add_error(
              changeset,
              "#{arg_key} is invalid or could not be converted to UTC"
            )
        end

      :error ->
        changeset
    end
  end

  defp do_convert_to_utc(nil, _), do: {:ok, nil}

  defp do_convert_to_utc(%DateTime{} = dt, _timezone) do
    DateTime.shift_zone(dt, "Etc/UTC")
  end

  defp do_convert_to_utc(%NaiveDateTime{} = naive, timezone) do
    with {:ok, dt_local} <- DateTime.from_naive(naive, timezone),
         {:ok, dt_utc} <- DateTime.shift_zone(dt_local, "Etc/UTC") do
      {:ok, dt_utc}
    end
  end

  defp do_convert_to_utc(value, timezone) when is_binary(value) do
    with {:ok, naive} <- NaiveDateTime.from_iso8601(value),
         {:ok, dt_local} <- DateTime.from_naive(naive, timezone),
         {:ok, dt_utc} <- DateTime.shift_zone(dt_local, "Etc/UTC") do
      {:ok, dt_utc}
    end
  end

  defp do_convert_to_utc(_, _), do: {:error, :invalid}
end

Note: DateTime.shift_zone/2 requires a timezone database. Add {:tzdata, "~> 1.1"} to your mix.exs dependencies and configure it:
config :elixir, :time_zone_database, Tzdata.TimeZoneDatabase

Setting the timezone in context

To apply the conversion correctly, the user's timezone should be passed in the Ash changeset context.

Ash 3.x (domain-based):

AshPhoenix.Form.for_action(MyApp.Event, :schedule,
  domain: MyApp.Domain,
  as: :event,
  context: %{user_timezone: "Europe/Brussels"}
)

Ash 2.x (api-based):

AshPhoenix.Form.for_action(MyApp.Event, :schedule,
  api: MyApp.Api,
  as: :event,
  context: %{user_timezone: "Europe/Brussels"}
)

Summary

Store all datetime attributes in UTC.
Accept user-local input via custom arguments.
Use a reusable Ash.Resource.Change module to convert values to UTC.
Pass the user's timezone via context on the changeset.
Handle strings, NaiveDateTime, DateTime, and nil values gracefully.

This pattern keeps your Ash resources clean and your time handling robust across different timezones.

#database #elixir #phoenix #postgresql #sql

🐥 Building a lift scheduling algorithm in Python

2026-10-11T17:00:00Z

A lift looks simple from the outside: press a button, wait, and eventually it arrives. Internally, however, a lift controller is a scheduling problem.

With multiple lifts and multiple passengers, the controller needs to decide which lift should handle which request, while trying to minimise waiting time, travel time, and unnecessary stops.

Let's build a simplified version in Python.

Start with a single lift

A lift needs to keep track of its current state:

from dataclasses import dataclass, field


@dataclass
class Lift:
    floor: int
    direction: str | None = None
    targets: set[int] = field(default_factory=set)

A simple controller can use the LOOK scheduling algorithm to select the next floor.

LOOK works like this:

Continue in the current direction while there are targets in that direction.
Visit the closest target in that direction.
When there are no more targets in that direction, reverse.
If there are no targets at all, become idle.

def next_target(lift: Lift) -> int | None:
    if not lift.targets:
        lift.direction = None
        return None

    if lift.direction is None:
        lift.direction = (
            "up"
            if min(lift.targets) > lift.floor
            else "down"
        )

    if lift.direction == "up":
        above = [
            floor
            for floor in lift.targets
            if floor > lift.floor
        ]

        if above:
            return min(above)

        lift.direction = "down"

    if lift.direction == "down":
        below = [
            floor
            for floor in lift.targets
            if floor < lift.floor
        ]

        if below:
            return max(below)

        lift.direction = "up"

    # If we get here, there are targets but none in the
    # current direction. Pick the closest one and establish
    # the corresponding direction.
    target = min(
        lift.targets,
        key=lambda floor: abs(floor - lift.floor),
    )

    lift.direction = (
        "up" if target > lift.floor else "down"
    )

    return target

For example:

Lift:       5
Requests:   2, 4, 6, 8, 10
Direction:  up

The lift visits:

5 → 6 → 8 → 10 → 8 → 6 → 4 → 2

However, that example exposes an important implementation detail: once a target has been served, it must be removed from the target set.

A simple simulation might therefore look like this:

def serve_next(lift: Lift) -> None:
    target = next_target(lift)

    if target is None:
        return

    lift.floor = target
    lift.targets.remove(target)

Now the route is correctly:

5 → 6 → 8 → 10 → 4 → 2

The lift continues upwards until there are no targets above it, then reverses direction.

A simpler implementation

We can make the LOOK behaviour more explicit by separating target selection from state changes:

def next_target(lift: Lift) -> int | None:
    if not lift.targets:
        return None

    if lift.direction == "up":
        above = sorted(
            floor for floor in lift.targets
            if floor > lift.floor
        )

        if above:
            return above[0]

        lift.direction = "down"

    elif lift.direction == "down":
        below = sorted(
            floor for floor in lift.targets
            if floor < lift.floor
        )

        if below:
            return below[-1]

        lift.direction = "up"

    # The lift was idle, or has just changed direction.
    if lift.direction == "up":
        above = [
            floor for floor in lift.targets
            if floor > lift.floor
        ]
        if above:
            return min(above)

    if lift.direction == "down":
        below = [
            floor for floor in lift.targets
            if floor < lift.floor
        ]
        if below:
            return max(below)

    return None

The important distinction from a naive implementation is that LOOK does not choose the globally closest floor.

Given:

Current floor: 5

Targets:
4
6
10

and direction up, the next target is:

not:

Even though both are equally close, the lift is already travelling upwards.

After serving 6 and 10, it reverses:

5 → 6 → 10 → 4

That's the defining behaviour of LOOK.

Hall requests are different

There are actually two kinds of requests.

A passenger inside the lift says:

I want to go to floor 10.

A passenger outside says:

I'm on floor 5 and want to go up.

The second request also has a direction.

@dataclass
class HallRequest:
    floor: int
    direction: str  # "up" or "down"

This matters because a lift travelling upwards shouldn't necessarily stop for someone waiting to travel downwards.

For example, if the lift is travelling:

2 → 5 → 8 → 10

a request on floor 4 for a downward journey doesn't necessarily belong on that route.

The controller should generally prioritise requests matching its current direction.

Multiple lifts

Now the problem gets more interesting.

Imagine three lifts:

Lift A: floor 2, going up
Lift B: floor 8, idle
Lift C: floor 15, going down

Someone on floor 6 presses the up button.

The obvious solution is to choose the closest lift. But that's not necessarily optimal.

Instead, we can give every lift a score.

def score(lift: Lift, request: HallRequest) -> float:
    distance = abs(lift.floor - request.floor)

    if lift.direction == request.direction:
        direction_penalty = 0
    elif lift.direction is None:
        direction_penalty = 2
    else:
        direction_penalty = 10

    return distance + direction_penalty

We can then select the lowest-scoring lift:

def assign_lift(
    lifts: list[Lift],
    request: HallRequest,
) -> Lift:
    return min(lifts, key=lambda lift: score(lift, request))

This is already considerably better than simply selecting the nearest lift.

Simulating the cost

A more sophisticated controller doesn't just ask:

How far away is this lift?

It asks:

How much additional work will this request cause?

Consider a lift currently at floor 3 with these destinations:

7, 10, 15

A new passenger wants to go from floor 5 to floor 12.

The existing route might be:

3 → 7 → 10 → 15

Adding the passenger changes it to:

3 → 5 → 7 → 10 → 12 → 15

The difference between those routes is the cost of accepting the request.

We can model this with a cost function:

def request_cost(
    waiting_time: float,
    travel_time: float,
    additional_stops: int,
    direction_changes: int,
) -> float:
    return (
        waiting_time * 5
        + travel_time
        + additional_stops * 2
        + direction_changes * 10
    )

The weights are deliberately configurable.

For example, we might consider waiting five times more important than travel time because making somebody wait for a lift is generally worse than adding a few seconds to the journey of someone already inside.

Destination dispatch

Modern lift systems can go one step further.

Instead of pressing:

↑

and later selecting a destination inside the lift, the passenger enters the destination immediately:

Floor 5 → Floor 17

The controller therefore knows the complete journey before assigning a lift.

That allows it to group passengers with similar destinations.

For example:

could potentially be handled by the same lift.

The dispatcher can therefore optimise the entire route instead of treating every passenger as an independent request.

Separating the dispatcher from the lift

A useful architecture is to separate two responsibilities.

The dispatcher decides:

Which lift should handle this request?

The lift controller decides:

Which floor should I visit next?

In Python, that could look like:

class Dispatcher:
    def __init__(self, lifts: list[Lift]):
        self.lifts = lifts

    def assign(self, request: HallRequest) -> Lift:
        return min(
            self.lifts,
            key=lambda lift: score(lift, request),
        )

The lift itself can remain responsible for its own state:

class LiftController:
    def __init__(self, lift: Lift):
        self.lift = lift

    def add_target(self, floor: int) -> None:
        self.lift.targets.add(floor)

    def next_floor(self) -> int | None:
        return next_target(self.lift)

This separation makes the system much easier to reason about and test.

Model it as a state machine

A real controller would also have explicit states:

from enum import Enum


class LiftState(Enum):
    IDLE = "idle"
    MOVING_UP = "moving_up"
    MOVING_DOWN = "moving_down"
    DOOR_OPENING = "door_opening"
    DOOR_OPEN = "door_open"
    DOOR_CLOSING = "door_closing"

Events then cause state transitions:

IDLE
  ↓ request above
MOVING_UP
  ↓ target reached
DOOR_OPENING
  ↓
DOOR_OPEN
  ↓
DOOR_CLOSING
  ↓
MOVING_UP

This becomes particularly useful once you need to handle things such as emergency stops, overloaded lifts, door obstruction, and new requests arriving while the lift is moving.

The interesting part is the optimisation

The basic mechanics of a lift are relatively straightforward.

The difficult part is deciding what optimal means.

A real controller might try to minimise:

total waiting time
+ total travel time
+ number of stops
+ direction changes
+ energy consumption
+ passenger congestion

And these objectives can conflict.

Optimising one passenger's journey may make everybody else's journey worse.

That's why lift scheduling is a useful example of a broader class of software problems: resource allocation under changing constraints.

The same pattern appears in job schedulers, CPU scheduling, delivery routing, database query planning, and many other systems.

You don't necessarily need to find the mathematically perfect solution. A good practical approach is often:

Model the current state.
Generate possible decisions.
Estimate the cost of each decision.
Pick the lowest-cost option.
Recalculate when the state changes.

For a lift, that's enough to go from a simple "nearest lift wins" implementation to a surprisingly sophisticated scheduling system.

#development #pattern #python

🐥 Cross-schema queries in PostgreSQL without the loop

2026-10-08T17:00:00Z

Schema-based multi-tenancy is a popular pattern in PostgreSQL SaaS applications. Each tenant gets its own schema — tenant_1, tenant_2, and so on — with an identical table structure but fully isolated data. The application layer queries the right schema at runtime, and the database enforces the separation cleanly.

The headache arrives when you need to query across tenants: a one-off data audit, a cross-tenant report, a support investigation. The table exists in every schema, but there is no built-in SELECT * FROM ALL SCHEMAS syntax. You have to build that query yourself.

The procedural approach

The first instinct is usually a loop. Iterate over every tenant schema, query the table in each one, and collect the results somewhere. In PL/pgSQL:

-- Step 1: Create a staging table using the first tenant's column structure
DO $$
DECLARE
    sch text;
BEGIN
    FOR sch IN
        SELECT nspname
          FROM pg_namespace
         WHERE nspname LIKE 'tenant\_%' ESCAPE '\'
         ORDER BY nspname
         LIMIT 1
    LOOP
        EXECUTE format(
            'CREATE TEMP TABLE all_records AS
             SELECT %L::text AS tenant, * FROM %I.orders WHERE false',
            sch, sch
        );
    END LOOP;

    -- Step 2: Populate from every tenant schema
    FOR sch IN
        SELECT nspname
          FROM pg_namespace
         WHERE nspname LIKE 'tenant\_%' ESCAPE '\'
         ORDER BY nspname
    LOOP
        EXECUTE format(
            'INSERT INTO all_records
             SELECT %L::text AS tenant, * FROM %I.orders',
            sch, sch
        );
    END LOOP;
END $$;

SELECT * FROM all_records ORDER BY tenant;
DROP TABLE all_records;

This works. The first loop borrows a schema's column structure to create the temp table; the second loop populates it. But there is an awkward quality to it: two loops, two passes over pg_namespace, and a DO block that can't return rows directly, so a temp table is required as a staging area.

The set-based approach

PostgreSQL's string_agg function lets you collapse the entire loop into a single expression. Instead of visiting schemas one at a time, you assemble the full UNION ALL query string in one pass, then execute it once:

DO $$
DECLARE
    sql text;
BEGIN
    SELECT string_agg(
        format(
            'SELECT %L::text AS tenant, * FROM %I.orders',
            nspname, nspname
        ),
        ' UNION ALL '
        ORDER BY nspname
    )
    INTO sql
    FROM pg_namespace
    WHERE nspname LIKE 'tenant\_%' ESCAPE '\';

    EXECUTE 'CREATE TEMP TABLE all_records AS ' || sql;
END $$;

SELECT * FROM all_records ORDER BY tenant;
DROP TABLE all_records;

No loop. string_agg scans pg_namespace once and produces a string like:

SELECT 'tenant_1'::text AS tenant, * FROM tenant_1.orders
UNION ALL
SELECT 'tenant_2'::text AS tenant, * FROM tenant_2.orders
UNION ALL
SELECT 'tenant_3'::text AS tenant, * FROM tenant_3.orders

A single EXECUTE then runs that string wrapped in a CREATE TEMP TABLE AS, which also infers the column structure automatically — no need for a separate setup step.

Breaking It Down

Element	What it does
`pg_namespace`	PostgreSQL's system catalog table for schemas. Filter by `nspname` to target tenant schemas.
`format('%I', …)`	Safely quotes an identifier (schema name, table name). Prevents SQL injection in dynamic queries.
`format('%L', …)`	Safely quotes a string literal. Used here to emit the tenant name as a constant in each sub-query.
`string_agg(…, ' UNION ALL ')`	Joins all sub-queries into one SQL string. The `ORDER BY` clause ensures a deterministic join order.
`CREATE TEMP TABLE AS …`	Creates a temporary table whose columns are inferred from the query result. Scoped to the session and dropped automatically when the connection closes.

On format() and injection safety — Always use %I for identifiers and %L for literals when building dynamic SQL with format(). They handle quoting and escaping correctly, even for edge cases like schema names containing reserved words or special characters.

When to reach for this

This pattern is well suited to ad-hoc, operational queries:

Cross-tenant reporting and aggregations
Data consistency audits across all schemas
Support investigations that span multiple tenants
One-off backfill or data migration checks
Debugging anomalies that may appear in only some tenants

For production cross-tenant queries that run on a schedule, a dedicated reporting schema or a materialized view strategy is usually a better fit. Dynamic SQL assembled at query time adds latency and bypasses the planner's ability to optimize across tenants as a whole.

The underlying idea

The loop version is imperative: it tells the database how to visit each schema. The string_agg version is declarative: it describes the result it wants and lets a single EXECUTE handle execution. That shift is modest here, but it reflects a broader principle in SQL — set-based operations tend to be shorter, easier to read, and easier to extend than their procedural equivalents.

Adding a filter is illustrative. In the loop version you modify the format string inside the loop body and track whether you've touched it everywhere. In the string_agg version you change the format string in one place:

SELECT string_agg(
    format(
        'SELECT %L::text AS tenant, * FROM %I.orders WHERE status = ''pending''',
        nspname, nspname
    ),
    ' UNION ALL '
    ORDER BY nspname
)
INTO sql
FROM pg_namespace
WHERE nspname LIKE 'tenant\_%' ESCAPE '\';

One change, one place. The loop version requires the same change inside the loop body, with the same effect — but the set-based version makes the scope of the change obvious at a glance.

#database #postgresql #sql

🔗 ID design and primary keys, pt. 1

2026-09-27T17:00:00Z

Is your database design stunted by traditional approaches? Alexey Makhotkin delves into a refreshing take on primary keys and ID design. He highlights the importance of aligning primary key selection with business requirements rather than sticking to conventional database norms. Through engaging examples, he introduces the concept of external IDs and anchor IDs, demonstrating how they relate to database entities. Makhotkin also emphasizes the significance of immutable anchor IDs for unique identification, plus the nuances of using external IDs effectively, even those from outside systems. By analyzing a minimal content management scenario, he shows the logical modeling with integer primary keys and uniqueness constraints, setting a strong foundation for understanding primary keys in database design. Part two promises to further explore the complexities of composite primary keys, making this a must-read for database enthusiasts.

Continue reading on anchorsandlinks.com

🐥 Natural sorting in Laravel API resources

2026-09-16T17:00:00Z

When exposing related collections through Laravel API Resources, the default order is whatever the database returns — usually insertion order. For user-facing lists, that's rarely what you want.

The Problem

A resource with a belongsToMany relation would return items in an arbitrary order:

'items' => ItemResource::collection($this->whenLoaded('items')),

Items named "Item 2" and "Item 10" would sort lexicographically: Item 10, Item 2 — not what a user expects.

The Fix

whenLoaded accepts a callback that runs only when the relation is loaded. Use it to sort the collection before handing it off to the resource:

'items' => ItemResource::collection(
    $this->whenLoaded('items', fn () => $this->items->sortBy('name', SORT_NATURAL | SORT_FLAG_CASE))
),

SORT_NATURAL gives you human-friendly ordering (Item 1, Item 2, Item 10). SORT_FLAG_CASE makes it case-insensitive. The callback is only invoked when the relation is loaded, so lazy-loading is never triggered accidentally.

Testing It

The key assertion is that numeric suffixes sort numerically, not lexicographically:

$item10 = Item::factory()->create(['name' => 'Item 10']);
$item2  = Item::factory()->create(['name' => 'Item 2']);
$item1  = Item::factory()->create(['name' => 'Item 1']);

$model->items()->attach([$item10->id, $item2->id, $item1->id]);
$model->load('items');

$result = (new ModelResource($model))->toArray(Request::create('/'));

$names = collect($result['items'])->pluck('name')->values()->all();
$this->assertSame(['Item 1', 'Item 2', 'Item 10'], $names);

Attach them out of order, load, assert the right order comes out. Simple and robust.

#laravel #php #best-practice #http #testing

🐥 Undoing a pushed merge commit without losing work

2026-09-12T17:00:00Z

Sometimes you push a merge commit you didn't mean to, and notice it only after the fact. Here's how we handled it cleanly when that happened on a feature branch.

My branch history looked like this:

abc1234  Fix for the feature we were working on  ← latest commit, must keep
def5678  Merge branch 'feature/my-branch' of ...  ← mistake
ghi9012  Previous commit
jkl3456  Older commit

The merge commit def5678 was already pushed to GitHub. The latest fix (abc1234) sat on top of it, so a plain git reset --hard HEAD~1 would have taken the fix with it.

I needed to drop exactly one commit from the middle of the history while keeping everything above it. git rebase --onto is the right tool for this:

git rebase --onto ghi9012 def5678 HEAD

This tells Git: take all commits after def5678 up to HEAD, and replay them directly onto ghi9012 — the commit before the bad merge. The merge commit is skipped entirely.

The rebase left us in a detached HEAD state, so we updated the branch pointer and switched back:

git branch -f feature/my-branch HEAD
git checkout feature/my-branch

The history was now clean:

xyz7890  Fix for the feature we were working on
ghi9012  Previous commit
jkl3456  Older commit

Then a force-push to update the remote:

git push --force

Why not git revert?

git revert -m 1 <hash> is the safer choice when multiple people have already pulled the branch, because it adds a new commit rather than rewriting history. In our case the branch was a personal feature branch with no other active collaborators, so rewriting was fine and kept the history cleaner.

When in doubt on a shared branch, revert. On a solo feature branch, rebase is cleaner.

#best-practice #terminal #git

🐥 Laravel boost best practices: A major tone shift (August 2026)

2026-09-07T17:00:00Z

Two commits landed in the Laravel Boost repository on August 26, 2026 that significantly update the AI guidance rules baked into the package. The changes touch all 19 best-practice rule files and add a new section on controller resource design. Here is what changed and why it matters.

The big picture: from prescriptive to contextual

The first commit (d165b9ea) touches 1,427 lines across every rule file. The headline change is not a new feature — it is a deliberate softening of absolute language.

Rules that previously said "Incorrect" / "Correct" now use labels like:

"Manual lookup:" / "Use route model binding:"
"Hidden dependency:" / "Injected dependency:"
"Unsafe:" / "Preferred:"
"Queued and durable:" / "Deferred in the current process:"

The intent is clear: the guidance now presents trade-offs and context instead of moral verdicts. This matters because AI coding agents (and developers) following these rules were previously being trained to treat "Incorrect" examples as always wrong, even in situations where the pattern was actually fine.

Key Changes by Area

Queries — `advanced-queries.md`

The old guidance said whereHas() was flat-out wrong because it "re-executes per row." The new version is more honest:

whereHas() typically produces an EXISTS subquery, while whereIn() can express the same filter with an IN subquery. Either form may be faster depending on the database engine, indexes, cardinality, and query plan. Measure both forms with representative data.

The section title changed from "Prefer whereIn + Subquery Over whereHas" to "Compare whereHas() with an IN Subquery". Similarly, the compound index rule now says "verify the query plan" rather than asserting a single correct approach.

A technical fix also snuck in: the dynamic relationship example now correctly passes the foreign key to belongsTo():

// Before (broken — missing the FK argument):
return $this->belongsTo(Login::class);

// After (correct):
return $this->belongsTo(Login::class, 'last_login_id');

Architecture — `architecture.md`

Two notable shifts:

Dependency injection: The old rule said constructor injection was always correct and method injection was a code smell. The new rule aligns with how Laravel actually works:

Prefer constructor injection for dependencies required throughout an object's lifetime. Method injection is appropriate for dependencies needed by one controller action, listener, job handler, or other container-invoked method.

Default sort order: Instead of "always use latest()", the guidance now recommends a stable two-column sort with a tie-breaker for reliable pagination:

Post::query()
    ->orderByDesc('created_at')
    ->orderByDesc('id')
    ->paginate();

Caching — `caching.md`

The Cache::remember() section now explicitly warns about the false-cache-miss bug:

The manual version below incorrectly treats valid falsy values, such as false or 0, as cache misses.

It also adds an honest caveat: Cache::remember() does not prevent concurrent requests from computing the same missing value — you still need Cache::lock() for that.

Routing — `routing.md`

The "Keep Controllers Thin" rule (with its arbitrary "under 10 lines" target) is gone. In its place:

Controllers should coordinate HTTP input, authorization, validation, an application operation, and the response. Extract substantial or reusable business logic, but do not introduce an action or service merely to satisfy an arbitrary line limit.

Migrations — `migrations.md`

The file shrank significantly (78 → 24 deletions vs. 24 additions). Several overly prescriptive examples were removed. The foreign-key section now includes a practical note:

Do not add a duplicate single-column index without checking the database driver's treatment of foreign-key indexes and the indexes already created by the migration.

Security — `security.md`

Two nuanced additions stand out:

$guarded = [] is no longer labeled universally "Incorrect." The new text acknowledges that mass-assignment protection controls which attributes can be set, not values or authorization — and that deliberate conventions using $guarded are valid.
The SQL injection example now uses the fluent string helper properly:

User::whereRaw('LOWER(name) = ?', [$request->string('name')->lower()->toString()])->get();

A new explicit note: "Public actions intentionally available to everyone do not need a redundant authorization check."

Queues — `queue-jobs.md`

The Amazon SQS footnote is new and important:

Amazon Simple Queue Service uses its visibility timeout instead of Laravel's retry_after; configure that timeout at the queue level.

The ShouldBeUnique section now notes that all dispatching processes must share a cache store that supports locks — a silent gotcha that has burned teams before.

New section: organize controllers around resources

The second commit (b19e98a8) adds a standalone section to routing.md covering a pattern that often gets debated on Laravel teams.

The guidance establishes a clear default: organize controllers around one resource using standard resource actions (index, show, create, store, edit, update, destroy). When a custom verb like publish, approve, or archive appears, treat it as a design signal — it might represent a separate resource.

The canonical example models podcast publishing as a dedicated controller:

// Route
Route::post('/published-podcasts/{podcast}', [PublishedPodcastController::class, 'store'])
    ->name('published-podcasts.store');

Route::delete('/published-podcasts/{podcast}', [PublishedPodcastController::class, 'destroy'])
    ->name('published-podcasts.destroy');

// Controller
class PublishedPodcastController extends Controller
{
    public function store(Podcast $podcast): RedirectResponse
    {
        $podcast->publish();
        return back();
    }

    public function destroy(Podcast $podcast): RedirectResponse
    {
        $podcast->unpublish();
        return back();
    }
}

The guidance ends with an important escape hatch:

Treat a custom verb as a design signal, not proof that another controller is required. Use query parameters for simple filtering, and keep an explicit action route when modeling the operation as a resource would obscure the domain or conflict with established project conventions.

Why this matters for AI-assisted development

Laravel Boost feeds these rules directly to AI coding agents as context when generating code. Overly prescriptive "always/never" rules cause agents to reject valid patterns and to add unnecessary abstractions (action classes for trivial logic, for example). The new tone should lead to more pragmatic, context-aware suggestions — and fewer unnecessary "Incorrect" rewrites of perfectly reasonable code.

The shift also signals a broader direction: good AI guidance reads like a senior developer explaining trade-offs, not a linter listing violations.

#laravel #best-practice #ai

🐥 One line to measure PHP memory

2026-09-05T17:00:00Z

You've just run a long-running Artisan command and production is complaining about memory. Before reaching for Xdebug or a full profiler, there's a tool already on your machine that answers the question in one line:

/usr/bin/time -l php artisan your:command 2>&1 | grep "maximum resident"

That's it. No code changes, no instrumentation, no deployment.

Breaking it down

/usr/bin/time — the system binary, not the shell built-in. The full path is important: your shell likely has a time built-in that doesn't support the -l flag.
-l — tells it to emit detailed resource usage. On Linux, use -v instead.
2>&1 — time writes its output to stderr, so you need to redirect it into stdout before you can pipe it.
| grep "maximum resident" — filters down to the one line you care about.

The output looks like this:

 147922944  maximum resident set size

That number is in bytes. Divide by 1024 × 1024 and you have the peak RSS in megabytes — in this case, 141 MB. That's the high-water mark of physical RAM the process held at any one moment, and the right number to compare against memory_limit in php.ini.

Why not `memory_get_peak_usage()`?

PHP's own memory_get_peak_usage(true) is great when you control the code — add it at the end of handle() and you see PHP's internal allocator peak. But it only sees what PHP's memory manager tracked. The OS-level approach catches everything: the runtime itself, loaded extensions, forked child processes. For commands that spawn subprocesses or load large extensions, the two numbers can diverge meaningfully.

The OS measurement also requires no deployment — run it against production code on a staging server without touching a line.

macOS vs. Linux

Swap -l for -v on Linux. The field name also changes slightly — look for "Maximum resident set size (kbytes)" — and note the unit shift from bytes to kilobytes.

Drop the grep for more

Skip the pipe entirely and /usr/bin/time -l dumps the full resource table after your command finishes: page faults, context switches, I/O operations, wall time. Worth reading once to understand what your command is actually doing at the OS level.

#laravel #php #best-practice #terminal #sysadmin

🐥 Customizing the Laravel Boost guidelines

2026-09-02T17:00:00Z

In my current project, I'm using Laravel Boost to injects contextual guidelines into your AI coding assistant (Claude Code, Cursor, Copilot, etc.) by composing a set of named rule blocks — foundation, boost, php, laravel/core, deployments, and version-specific blocks like laravel/v13 — into the CLAUDE.md file at the root of your project.

One of the things that annoyed me is that this PR added marketing info from Laravel promoting their Laravel Cloud solution for deployment. As I'm not using it (and have no intentions to do so), after each update of the Boost guidelines, I needed to manually remove this part:

# Deployment

- Laravel can be deployed using [Laravel Cloud](https://cloud.laravel.com/), which is the fastest way to deploy and scale production Laravel applications.

It turns out there is another PR that offers a solution for this, PR #774.

It adds a small but useful quality-of-life improvement: the deployment guideline has been extracted from laravel/core into its own named block (deployments), and you can now exclude any named guideline block from being injected via a config option.

To exclude these guidelines, first start with publishing the Boost config if you haven't already:

php artisan vendor:publish --tag=boost-config

Then add the guidelines key to config/boost.php:

return [
    // ...

    'guidelines' => [
        'exclude' => [
            'deployments',
        ],
    ],
];

After the next boost:update run, the === deployments rules === block will no longer appear in your CLAUDE.md.

AI coding assistants consume every line of your guidelines as context on every request. Irrelevant rules waste tokens and can subtly steer the model toward unhelpful suggestions. If your team deploys to a custom pipeline, Kubernetes, or anything other than Laravel Cloud, the default deployment hint is pure noise — and now you can cleanly remove it without patching vendor files.

The same exclude mechanism works for any named guideline block, so as Boost gains more optional sections (versioned package rules, framework-specific hints), you'll be able to keep your injected context lean and project-relevant.

If you want to keep deployment guidance but tailor it to your stack, the PR also documents the override path: create .ai/deployments/core.blade.php in your project root and write your own instructions there. Boost picks up local overrides before falling back to its own templates, so your custom block replaces the default without needing the exclude config at all.

#laravel #php #ai #devops

🐥 Building a Laravel-style event system in Elixir Phoenix

2026-08-31T17:00:00Z

Laravel's events and listeners are a fantastic way to decouple your application. You dispatch an event, register one or more listeners, and each listener reacts independently. It's a simple pattern that keeps your code clean.

Phoenix doesn't provide an equivalent abstraction out of the box, but OTP and Phoenix PubSub make it straightforward to build something similar while remaining idiomatic.

Publishing domain events

Rather than having models emit events automatically, publish events from your contexts after a successful database operation.

def update_user(user, attrs) do
  old = user

  with {:ok, user} <- User.changeset(user, attrs) |> Repo.update() do
    Events.publish(%Events.UserUpdated{
      old: old,
      new: user,
      actor_id: attrs[:actor_id]
    })

    {:ok, user}
  end
end

Notice that the event describes a business action (UserUpdated) rather than a database operation.

Creating an event bus

A small wrapper around Phoenix PubSub provides a central place for publishing events.

defmodule MyApp.Events do
  @topic "events"

  def publish(event) do
    Phoenix.PubSub.broadcast(
      MyApp.PubSub,
      @topic,
      {:event, event}
    )
  end
end

This gives you an API similar to Laravel's event(...) helper.

Listening for events

Listeners are simply GenServers that subscribe to your event topic.

defmodule MyApp.Audit.Listener do
  use GenServer

  def start_link(_) do
    GenServer.start_link(__MODULE__, %{})
  end

  def init(state) do
    Phoenix.PubSub.subscribe(MyApp.PubSub, "events")
    {:ok, state}
  end

  def handle_info({:event, event}, state) do
    handle_event(event)
    {:noreply, state}
  end

  defp handle_event(%Events.UserUpdated{} = event) do
    Audit.log(event)
  end

  defp handle_event(_), do: :ok
end

Adding additional listeners for emails, metrics, search indexing or webhooks is simply a matter of starting another GenServer.

Is this suitable for audit logging?

Not quite.

Phoenix PubSub is excellent for notifying other parts of your application, but it does not guarantee that a listener has successfully processed an event.

Imagine the following sequence:

Repo.update(...)
↓
Publish event
↓
Application crashes

The database change has been committed, but the audit record may never be written.

For an audit trail, that's usually unacceptable.

Use Ecto.Multi for audit logging

A more robust approach is to store the audit record in the same transaction as the database change.

Ecto.Multi.new()
|> Ecto.Multi.update(:user, changeset)
|> Ecto.Multi.insert(:audit_log, fn %{user: user} ->
  AuditLog.changeset(%AuditLog{}, %{
    entity: "user",
    entity_id: user.id,
    action: "updated"
  })
end)
|> Repo.transaction()

Now either both records are committed, or neither is.

Capturing the changes

You don't need to manually compare two structs. Ecto already tracks modified fields through the changeset.

changeset.changes

For more detailed audit logs, you can combine the original struct with the updated one to produce a before/after representation.

For example:

{
  "name": {
    "old": "John",
    "new": "Johnny"
  },
  "email": {
    "old": "john@example.com",
    "new": "johnny@example.com"
  }
}

This makes it easy to display exactly what changed in an audit history.

Putting it together

A pattern that has worked well for larger Phoenix applications is to separate business events from auditing:

Publish domain events with Phoenix PubSub for emails, search indexing, webhooks and other asynchronous work.
Persist audit logs inside the same database transaction using Ecto.Multi.
Offload expensive work to Oban jobs instead of executing it directly from listeners.

This gives you the same loose coupling as Laravel's event system while embracing Elixir's strengths: explicit processes, OTP supervision and reliable transactional guarantees.

#pattern #laravel #database #elixir #phoenix

🐥 Chaining GitHub Actions Workflows the right way

2026-08-25T17:00:00Z

If you've spent any time maintaining CI/CD pipelines, you've probably run into this situation: a workflow that deploys your app, and some follow-up work that should happen right after — posting a changelog, syncing release notes to a project tracker, notifying a downstream system. The naive solution is to pile everything into the same workflow file. It works, but it doesn't stay clean for long.

A better option is to split the follow-up into its own workflow file and call it from the deployment workflow when needed. GitHub Actions supports this natively through reusable workflows, and once you understand how the wiring works, it's surprisingly straightforward.

GitHub Actions has a trigger type called workflow_call. When you add it to a workflow's on: block, that workflow becomes callable by other workflows in the same repository — similar to importing a function from another module. The calling workflow references it as a job using uses: with a relative path, instead of a runs-on + steps structure.

The pattern looks like this:

The reusable workflow (release-notes.yaml):

on:
  workflow_call:
  workflow_dispatch:  # keep this so you can still trigger it manually

The caller workflow (deploy.yaml):

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: ./deploy.sh

  post-release-notes:
    needs: [deploy]
    uses: ./.github/workflows/release-notes.yaml
    secrets: inherit

That's the whole thing. When the deploy job finishes, post-release-notes kicks off by running the full release-notes.yaml workflow.

A few things worth knowing

Reusable workflows are jobs, not steps. This is a constraint that trips people up. You cannot nest a uses: directive inside a job's steps: block. It has to be a top-level job. If you need to call a reusable workflow conditionally (e.g., only on pushes to main), you do that with an if: on the job itself, not inside the workflow being called.
secrets: inherit does what you think. Without it, the called workflow has no access to secrets. You'd have to pass them explicitly via with: inputs, which is verbose. Using secrets: inherit passes the calling workflow's secrets through automatically, which is almost always what you want for internal reuse within a single repo.
The called workflow can still have its own triggers. Adding workflow_call doesn't replace whatever triggers were already there. A workflow that was previously only schedule-triggered can become reusable without breaking the scheduled runs. This is handy during a migration — you can add workflow_call first, wire up the caller, and verify everything works before removing any manual triggers.

Conditional execution on the caller side. When you have separate deploy jobs for different environments (staging vs. production), you'll often want separate caller jobs too, each with its own needs: and if: condition:

  post-release-notes-staging:
    needs: [deploy-staging]
    if: github.ref == 'refs/heads/develop'
    uses: ./.github/workflows/release-notes.yaml
    secrets: inherit

  post-release-notes-production:
    needs: [deploy-production]
    if: github.ref == 'refs/heads/main'
    uses: ./.github/workflows/release-notes.yaml
    secrets: inherit

Each one runs independently after its respective deploy job, on the appropriate branch.

You could trigger a workflow via the GitHub API with a curl call to the workflow_dispatch endpoint — and this is sometimes the right move when the target workflow lives in a different repository. But within the same repo, it's an awkward fit. You're introducing an async HTTP call where a direct dependency would do, you lose visibility into the triggered run from the calling workflow's summary page, and you have to handle auth tokens explicitly.

With workflow_call, the called workflow appears as a regular job in the same run. It shows up in the same Actions UI view, its logs are right there, and failures propagate naturally without any custom error handling.

The main practical benefit of this approach isn't just reusability — it's that it lets you keep each workflow file focused on one thing. A deployment workflow shouldn't have to know about Jira, or Slack, or whatever notification system you're using. That logic belongs in its own file, tested and maintained separately, triggered wherever it's needed.

Reusable workflows are one of the more underused features of GitHub Actions. The documentation covers them, but the examples tend to stop at "here's the syntax." In practice, the pattern of splitting post-deployment tasks into callable workflows — and composing them from the main CI/CD pipeline — scales well as pipelines grow and keeps things readable as teams expand.

If your deployment workflow is getting long, it's worth looking at what could be pulled out into a reusable workflow. Chances are, more of it is portable than you'd expect.

#devops #github

🐥 Faster, leaner MySQL backups and restores with mysqldump

2026-08-22T17:00:00Z

mysqldump is a perfectly fine tool for many production workloads — until your database grows large enough that backups take too long and restores take even longer. Before you reach for a more exotic solution, there are several flags and session-level variables that can make a meaningful difference with zero infrastructure changes.

This article focuses on plain MySQL, but shows where to wire up these settings when you use spatie/laravel-backup and stefanzweifel/laravel-backup-restore in a Laravel project.

Where to configure this in Laravel

Both packages read dump and restore options from config/database.php, inside the dump key of your connection:

// config/database.php
'mysql' => [
    // ... standard connection settings ...
    'dump' => [
        'excludeTables' => [...],
        'useSingleTransaction' => true,
        'add_extra_option' => '...', // passed to mysqldump (backup)
        'options' => '...',          // passed to mysql client (restore)
    ],
],

add_extra_option is forwarded to mysqldump by spatie/laravel-backup.
options is forwarded to the mysql client by laravel-backup-restore.

Everything below maps directly to one of those two keys.

Dump-time optimisations

Exclude noisy, non-essential tables

Some tables accumulate millions of rows that are useful for debugging but worthless in a restore. Excluding them shrinks the dump file and cuts restore time dramatically.

'excludeTables' => [
    'telescope_entries',
    'telescope_entries_tags',
    'telescope_monitoring',
],

Laravel Telescope is the classic example: it can easily outweigh the rest of your schema combined.

Use a single transaction

--single-transaction

In spatie/laravel-backup this is:

'useSingleTransaction' => true,

This wraps the dump in a START TRANSACTION so InnoDB tables are read from a consistent snapshot without locking them. Essential for any live database.

Increase `--net-buffer-length`

--net-buffer-length=16777216   # 16 MB (default is 1 MB)

mysqldump groups rows into multi-row INSERT statements. The default maximum per statement is 1 MB. Raising it to 16 MB reduces the total number of statements in the file, which directly cuts parse and execution time during a restore.

Pair it with --max_allowed_packet on the server side:

--max_allowed_packet=512M

Without this, large packets are silently rejected.

Skip unnecessary LOCK/UNLOCK statements

--skip-add-locks

mysqldump normally wraps each table dump in LOCK TABLES … WRITE / UNLOCK TABLES. This is redundant when you are already using --single-transaction and when you disable table locking at restore time (see below). Removing these statements makes the dump file smaller and the restore faster.

Suppress MySQL 8 column statistics

--column-statistics=0

MySQL 8's mysqldump emits ANALYZE TABLE statements to update column statistics after each table is imported. On large tables these can block progress noticeably. If you run your own statistics collection after a restore, suppress them.

Compress the dump on the wire

--compression-algorithms=zlib

Compresses data in transit between mysqldump and the MySQL server. Useful when the client and server are on separate hosts, reducing network I/O. For socket connections the benefit is minimal, but there is no downside.

Skip binary log tracking (GTID)

--set-gtid-purged=OFF

If you use GTID-based replication, mysqldump normally writes SET @@GLOBAL.gtid_purged into the dump. During a restore this can conflict with an existing gtid_executed set. Passing OFF omits that statement and keeps restores clean on secondary or development databases.

Avoid table-level locks

--lock-tables=false

When using --single-transaction, table-level locking is already unnecessary. Explicitly disabling it avoids a redundant flush.

Use `--quick` for large tables

--quick

By default mysqldump buffers an entire table in memory before writing. --quick streams one row at a time, keeping memory usage flat regardless of table size. Always enable it for any production database.

Restore-time optimisations

These are passed to the mysql client via an --init-command, which MySQL executes before the dump is processed:

SET sql_log_bin=0;
SET foreign_key_checks=0;
SET unique_checks=0;
SET autocommit=0;

In config/database.php:

'options' => '--init-command="SET sql_log_bin=0; SET foreign_key_checks=0; SET unique_checks=0; SET autocommit=0;"',

`SET sql_log_bin=0`

Disables binary logging for the session. There is no point logging every INSERT from a dump file into the binlog — it inflates the binlog and slows the restore. Safe when you control the import and are not relying on the binlog to propagate changes to replicas. This also reduces the amount of disk space needed for the restore.

`SET foreign_key_checks=0`

MySQL enforces referential integrity row-by-row during inserts. In a full dump, the parent and child rows are all present — you just may not have inserted the parent yet when a child arrives. Disabling this check lets MySQL trust the dump and skip the per-row lookups, which is one of the most impactful restore optimisations available.

Re-enable it (or restart the session) after the restore to verify the restored data is consistent.

`SET unique_checks=0`

Similar rationale: MySQL normally verifies unique constraints on every insert. A correctly generated dump has no duplicates, so this check is redundant overhead. Disabling it reduces index update cost during the restore.

`SET autocommit=0`

Turns off the implicit COMMIT after every statement. Combined with the large INSERT batches produced by --net-buffer-length, this means the storage engine can batch many rows into a single transaction, dramatically reducing fsync pressure.

Putting it together

// config/database.php
'dump' => [
    'excludeTables' => [
        'telescope_entries',
        'telescope_entries_tags',
        'telescope_monitoring',
    ],
    'useSingleTransaction' => true,
    'add_extra_option' => '--set-gtid-purged=OFF --lock-tables=false --quick'
        . ' --max_allowed_packet=512M --net-buffer-length=16777216'
        . ' --compression-algorithms=zlib'
        . ' --skip-add-locks --column-statistics=0',
    'options' => '--init-command="SET sql_log_bin=0; SET foreign_key_checks=0; SET unique_checks=0; SET autocommit=0;"',
],

These settings are safe for the vast majority of production MySQL 8 setups. The restore-side flags assume you trust the dump and will verify data integrity via application-level health checks afterwards — which is standard practice regardless of how you import.

The backup side produces a smaller file, faster. The restore side skips redundant constraint checking and batches commits. Together they can reduce both phases by a significant margin without changing anything about your infrastructure or your backup tooling.

More info

#laravel #best-practice #mysql #devops

🐥 Speeding up our PHP test suite with a GitHub Actions matrix strategy

2026-08-20T17:00:00Z

Our test suite had become a bottleneck. Every push to develop or main triggered three separate CI jobs — unit tests, feature tests, and integration tests — each running sequentially after the previous one finished and each downloading the same apt packages from scratch. The result: slow feedback loops and a lot of redundant work.

This post walks through the changes we made to fix that.

The Problem: Three Jobs, Lots of Duplication

Before this change, the CI pipeline defined three independent jobs:

phpunit-unit:
  name: "PHP Unit Tests"
  steps:
    - name: Install packages
      run: |
        sudo apt update
        sudo apt install -y package-a package-b package-c
    - name: Execute tests
      run: php artisan test --parallel tests/Unit

phpunit-feature:
  name: "PHP Feature Tests"
  steps:
    # same apt install block...
    - name: Execute tests
      run: php artisan test --parallel tests/Feature

phpunit-integration:
  name: "PHP Integration Tests"
  steps:
    # same apt install block again...
    - name: Execute tests
      run: php artisan test --parallel tests/Integration

Each job was:

Checking out the repo independently
Setting up PHP independently
Installing Composer dependencies independently (even with caching, cache restores take time)
Running apt-get install with the same packages — every single time, with no caching

Step 1: Collapsing Three Jobs into a Matrix

The first change replaced the three separate job definitions with a single phpunit job that uses GitHub Actions' matrix strategy:

phpunit:
  name: "PHP Tests (${{ matrix.suite }})"
  runs-on: ubuntu-latest
  strategy:
    fail-fast: false
    matrix:
      include:
        - suite: unit-a
        - suite: unit-b
        - suite: feature-a
        - suite: feature-b
        - suite: Integration

All suites run in parallel, with fail-fast: false so a failure in one suite doesn't cancel the others mid-run.

The Execute tests step became a single parameterised command:

- name: Execute tests
  run: php artisan test --parallel --testsuite=${{ matrix.suite }} --coverage-clover test-coverage/coverage-${{ matrix.suite }}.xml

Why More Suites Instead of Fewer?

The original split was coarse: all unit tests ran together, and all feature tests ran together. One large bucket would hold everything up even when most of the tests in it finished quickly.

By naming suites explicitly in phpunit.xml, we got finer-grained parallelism:

<testsuite name="unit-a">
  <directory suffix=".php">./tests/Unit/GroupA</directory>
</testsuite>
<testsuite name="unit-b">
  <directory suffix=".php">./tests/Unit/GroupB</directory>
  <directory suffix=".php">./tests/Unit/GroupC</directory>
</testsuite>
<testsuite name="feature-a">
  <directory suffix=".php">./tests/Feature/GroupA</directory>
</testsuite>
<testsuite name="feature-b">
  <directory suffix=".php">./tests/Feature/GroupB</directory>
  <directory suffix=".php">./tests/Feature/GroupC</directory>
</testsuite>

This keeps each matrix leg roughly balanced in terms of test count and makes the overall wall-clock time shorter than when one slow bucket holds everything up.

Step 2: Caching apt Packages

The most wasteful part of the old setup was reinstalling the same system packages on every runner, for every job, from scratch. apt-get install isn't slow in absolute terms, but multiplied across five parallel jobs and every CI run, it adds up.

We replaced the raw apt install block with awalsh128/cache-apt-pkgs-action:

- name: Install packages
  uses: awalsh128/cache-apt-pkgs-action@latest
  with:
    packages: package-a package-b package-c
    version: ${{ hashFiles('.apt-packages') }}

The version key is tied to a .apt-packages lockfile committed to the repo. The cache is invalidated only when that file changes — not on every push — so the common case is a fast cache hit rather than a full install.

Any post-install configuration that previously lived inside the install block becomes its own named step. The action calls it only on a cache miss, so it doesn't run unnecessarily on cache hits:

- name: Post-install configuration
  run: # your configuration command here

The Downstream Effect: Coverage Merging

Any job that previously depended on the three separate job names now depends on the single phpunit job:

some-downstream-job:
  needs: [
    "phpunit",   # was: phpunit-unit, phpunit-feature, phpunit-integration
    ...
  ]

And the coverage merge step includes one file per suite:

./clover-merge -o coverage.xml \
  unit-a/coverage-unit-a.xml \
  unit-b/coverage-unit-b.xml \
  feature-a/coverage-feature-a.xml \
  feature-b/coverage-feature-b.xml \
  integration/coverage-integration.xml

What This Changes

Before	After
3 jobs, one per test type	5 jobs, all parallel
`apt install` on every run, every job	Cached apt packages, invalidated only on lockfile change
Coarse path-based test selection	Named testsuites in `phpunit.xml`
~3× duplicated job boilerplate	Single parameterised job definition

The wall-clock time for the PHP test stage drops because the legs run concurrently and the apt install step is usually a cache hit. Maintenance is easier too — adding a new suite is a two-line change: one entry in phpunit.xml and one entry in the matrix include list.

#php #devops #github #testing

🐥 YellowDuck.be

🐥 Passing Structs with a Rust NIF in Elixir

Define a struct in Elixir

Define the same struct in Rust

Write a NIF function that uses the struct

Wire it up in Elixir

Call it from IEx

Notes

🐥 Creating a Simple Elixir NIF Using Rust

Set up your Elixir project

Generate the Rust NIF scaffold

Write a simple NIF in Rust

Define the Elixir wrapper

Build and test

🐥 Giving a Laravel Artisan Command an Alias

The short version

1. The $aliases property

2. The #[Aliases] attribute

3. Overriding configure()

What you get

Gotchas

🐥 rsync backups that respect your .gitignore

The problem with a bare rsync

Explicit excludes for the obvious offenders

Honouring .gitignore automatically

Why keep the explicit excludes too?

When --delete can't clean up after itself

The final script

🐥 ini_set('memory_limit') Now Throws in PHP 8.5

What happened

The PHP 8.5 change

The three real fixes

1. Raise max_memory_limit on the server (correct, if you own the server)

2. Pass the limit via the CLI (good for scheduled commands)

3. Suppress the error and accept the cap (quick, pragmatic)

4. Use -1 (unlimited)

What we did

How to find this in your own codebase

🐥 Smarter PR Size Labels with Weighted Scoring

Why bother labelling PR size?

The naive approach and its problems

The weighted scoring model

Three file categories

Thresholds

The not-reviewable label

Ignoring noise

The full workflow

Full workflow source

Things to keep in mind

🐥 Debugging a 502 on a Signed Redirect: nginx's "upstream sent too big header"

The symptom

Finding the root cause

Why it only fails in staging

The obvious fix and why to think twice

A better fix: move the URL out of the header

Why not use a URL shortener or cache indirection?

The diagnostic checklist

🐥 Why PHP's Recent Critical RCEs Are an Architectural Non-Problem in Elixir

Vulnerability 1: The OOM Partial Initialization Attack (CVE-2026-109618)

What Happened in PHP

Why It Is a Non-Problem in Elixir

Defensive Engineering: Monitoring BEAM Process Memory Thresholds

Vulnerability 2: Stale Worker Global State (CVE-2026-109619)

What Happened in PHP

Why It Is a Non-Problem in Elixir

Ecosystem Security: Managing Hex Third-Party Supply Chain Risks

Architecture as a Security Shield

Architectural & Security Feature Summary

🐥 Fixing "header_too_long" When Downloading Precompiled NIFs in Elixir

What's Going On?

Three Ways to Fix It

Option 1 — Download the NIF Manually with curl (Fastest)

Option 2 — Update the Dependency

Option 3 — Force Build from Source

Which Should You Choose?

The Broader Lesson

The Proper Fix

🐥 Streaming ZIP downloads in Phoenix with zstream

The idea

Adding the dependency

1. The `$aliases` property

2. The `#[Aliases]` attribute

3. Overriding `configure()`

1. Raise `max_memory_limit` on the server (correct, if you own the server)

4. Use `-1` (unlimited)

The `not-reviewable` label

Queries — `advanced-queries.md`

Architecture — `architecture.md`

Caching — `caching.md`

Routing — `routing.md`

Migrations — `migrations.md`

Security — `security.md`

Queues — `queue-jobs.md`

Why not `memory_get_peak_usage()`?