DEV Community: Eric Mollenthiel

Symfony 7.4 to 8.1, measured twice a month apart: two of the scary parts were fixed in patch releases

Eric Mollenthiel — Thu, 01 Oct 2026 17:22:18 +0000

On 26 August I measured what it costs to move a real Symfony codebase from 7.4 to 8.1: a kit with a few hundred tests, PHPStan at level max, Doctrine on PostgreSQL. Four lines of code, one failing test, zero new PHPStan errors, zero new deprecations, and one cache step that turns "the whole app returns 500" into "fine". I published those numbers in a Slack thread where a Symfony core contributor had rightly pushed back on a kit that pins the LTS, and they went into an upgrade guide.

Today I ran the same upgrade again, on the same codebase, four weeks and two patch releases later. Four of those five numbers changed. Two of the changes are Symfony patch releases fixing what I had blamed on the major, and one of those two bugs was in 7.4 too.

The bench

Two throwaway copies of the kit at the same commit (git archive, nothing touched in the real repository), PHP 8.5.7, Composer 2.9.7, a throwaway PostgreSQL 18.3 database. One copy stays on its lock file, Symfony 7.4. The other gets the upgrade:

every "7.4.*" in composer.json becomes "8.1.*" (26 occurrences, extra.symfony.require included);
require.php goes from >=8.4 to >=8.4.1 and config.platform.php from 8.4.0 to 8.4.1;
composer update --with-all-dependencies;
two method signatures widened;
the test suite, PHPStan, and the deprecations, on both copies.

The whole run is one shell script, and every number below comes from its output.

Then and now

                                        26 August (8.1.5)        24 September (8.1.7)
Resolution blocked by third-party       none                     none
Lines of application code to change     4, in 2 files            4, in 2 files
Failing tests                           1                        0 out of 483
Stale cache compiled under 7.4          every page 500           green
New PHPStan errors, level max           0                        2, not from Symfony
New deprecations from Symfony           0                        2

What did not move first, because it is still the part that looks worst and costs least.

The resolution fails with 22 problems, and none of them is a bundle. Every one reads like a third-party conflict and is the same line: symfony/... v8.1.0 requires php >=8.4.1 -> your php version (8.4.0; overridden via config.platform, actual: 8.5.7). The server runs 8.5; the platform pin in composer.json says 8.4.0, and 8.1 wants 8.4.1. Two lines, and the resolution goes through. It updates 100 packages today, installs 3 and removes 3.

The two breaking changes are fatal errors while the container is built, so nothing can slip through: Voter::voteOnAttribute() gains a ?Vote $vote = null parameter, and UserCheckerInterface::checkPostAuth() receives the token. PHP names the file and the line. That is the four lines.

The failing test was a patch regression, and it was in 7.4 too

In August, one test failed: a controller that streams server-sent events, where the body reached the test client empty. The status was 200, the Content-Type was text/event-stream, and the controller does what every SSE endpoint does after each event:

echo 'data: '.json_encode($payload, \JSON_THROW_ON_ERROR)."\n\n";
if (ob_get_level() > 0) {
    ob_flush();
}
flush();

The diagnosis at the time was correct as far as it went. HttpKernelBrowser::doRequest() in 8.1.5 captured the body with a plain ob_start() and read it back with ob_get_clean(). ob_flush() on a buffer without a callback pushes the content through to the parent buffer, so by the time ob_get_clean() runs there is nothing left. We wrote it down as "what changed in 8.x".

It was not 8.x. Today the test is green on 8.1.7, so I went looking for the version where it came back, and the answer is in symfony/http-kernel's history:

20 August: "Send the response content before terminating the kernel in the test client". That commit introduced the plain ob_start() in doRequest(), on the 6.4 branch, merged up.
22 August: released in 7.4.17 and 8.1.5.
23 August: "Capture flushed content in HttpKernelBrowser", which switches both capture points to ob_start() with a callback that accumulates each chunk and returns an empty string.
30 August: released in 7.4.18 and 8.1.6.

The proof that it is not a major-version change is to leave the 7.4 copy on 7.4 and move one package:

Symfony 7.4, http-kernel 7.4.13 (the kit's lock)   ChatTest  OK (7 tests)
Symfony 7.4, http-kernel 7.4.17                    ChatTest  1 failure, the same test
Symfony 7.4, http-kernel 7.4.18                    ChatTest  OK (7 tests)
Symfony 8.1, http-kernel 8.1.5                     ChatTest  1 failure
Symfony 8.1, http-kernel 8.1.7                     ChatTest  OK (7 tests)

The mistake in August was a comparison with two variables. The 7.4 reference ran on an http-kernel locked since May; the 8.1 branch had just resolved to a patch release that was four days old. Any project that ran composer update on 7.4 between 22 and 30 August and streams a response in a functional test saw the same failure, with no upgrade at all.

The 500s were a removed class, and 8.1.6 put a stub back

The other finding from August was that after the upgrade, every page returned a 500 on Class "Symfony\Component\VarExporter\Internal\Hydrator" not found until the cache directory was deleted. Symfony 8.1 had removed that internal class, and code exported by symfony/var-exporter under 7.4 (cache pools, in this case) still called it.

Replayed today with the test cache compiled under 7.4 copied into the 8.1 copy, and no cache:clear:

var-exporter 8.1.5   483 tests, 38 errors, 65 failures, 530 lines "Internal\Hydrator not found"
var-exporter 8.1.6   OK (483 tests)

On 29 August, symfony/var-exporter 8.1.6 added the class back as a stub whose only method throws a LogicException: "Code exported by symfony/var-exporter < 8.1 cannot be loaded anymore and must be regenerated." A cache pool treats the exception as a miss and regenerates the entry, where a missing class was a fatal error. Deleting var/cache after changing a major version is still the right habit. It is no longer the difference between a working app and a broken one.

Deprecations: the count depends on whether the container is compiled in that run

In August I wrote that Symfony 8 adds no deprecation to this codebase and removes one. The second half holds: the 7.4 deprecation about User::eraseCredentials() is gone on 8.1. The first half does not. Same suite, ignoreIndirectDeprecations off, run twice in a row, first with var/cache/test deleted, then with the container already compiled:

                         cold container    warm container
Symfony 7.4 (reference)        5                  3
Symfony 8.1.7                 19                 13

Two deprecations come from Symfony 8.1 and exist since 8.1.0, and both only show up in the cold run, because they are raised while the container is compiled:

Setting the "framework.profiler.collect_serializer_data" configuration option is deprecated. It will be removed in version 9.0. The kit sets it in web_profiler.yaml.
Relying solely on the name of parameter "$anthropicClient" of "__construct()" to match a named autowiring alias is deprecated; use the "#[Target]" attribute.

A run on a warm container reports neither. I cannot reconstruct the state of the cache during the August run, so I will not claim that is what happened then, but it is the simplest explanation for a zero. If you count deprecations to size an upgrade, delete var/cache/test first.

What `--with-all-dependencies` brings that is not Symfony

The rest of the new deprecations and both PHPStan errors come from packages that moved because -W let them:

twig/twig 3.29 deprecates calling a macro without a value for an argument that has no default (10 occurrences, one macro).
doctrine/orm deprecates passing a string as the direction to QueryBuilder::orderBy().
horstoeko/zugferd went from 1.0.123 to 1.0.132, and a tighter PHPDoc return type makes PHPStan flag an is_string() and an instanceof in a test as always true and always false. Pin it back to 1.0.123 on the 8.1 copy and PHPStan is at zero errors again.

None of that is the cost of Symfony 8.1, and all of it lands in the same pull request. When you size the upgrade, count the two separately, or a Twig macro and an e-invoicing library end up in the bill for Symfony 8.

What this does not measure

It measures the kit as it ships, not an application written on top of it: your own code has its own API surface. The SSE test passing again proves the test client captures the stream; it is still not a run in a real browser under 8.1. And one reproduction of the August state is missing: in my replay, cache:clear on the stale cache was enough to clean it, where the guide says it is not, so the only claim I keep is the one I could replay, delete the directory.

The codebase is ShipAnvil, a multi-tenant Symfony kit that stays pinned to 7.4 LTS: here is what the source code licence contains and costs. The upgrade guide it ships was written from the August run, and as of today three of its lines are wrong in the ways described above.

The general lesson is smaller than the numbers: when a major upgrade breaks something, install the same patch release of the failing component on the old branch before you blame the major.

Postgres RLS in Symfony: a setup check for a missing FORCE, and two ways it says "nothing to report" without looking

Eric Mollenthiel — Thu, 24 Sep 2026 15:07:23 +0000

Three articles ago I wrote that the Postgres role which runs your migrations bypasses every row-level security policy, unless the table has FORCE ROW LEVEL SECURITY. In the thread under the article before that one, @to21as made a proposal I had no argument against: a setup check does not have to impose FORCE or a separate role to be useful. It can just detect that the role serving the requests owns the tenant tables and that FORCE is off, and say so. Nothing imposed, and the buyer who deploys with CREATE DATABASE app_db OWNER app finds out at setup instead of never.

I agreed, and then I wrote the one thing I could not answer yet: what do those queries return for a serving role that is not the owner and cannot see what it does not own? A check that answers "nothing to report" because it cannot see the tables would be worse than no check at all.

I have the number now. The short answer is reassuring: the catalog does not have the hole I was afraid of. The long answer is that the check can still say "nothing to report" without looking, by two other routes, and one of them no query can fix.

The bench

PostgreSQL 18.3, a throwaway database, three roles. Three tenant tables, all created by the owner, which is what CREATE DATABASE app_db OWNER app followed by doctrine:migrations:migrate gives you. RLS enabled on all three, a tenant policy on each, and FORCE deliberately absent: that is the configuration the check is meant to catch. One of the tables, archive.audit_log, lives in a schema outside the default search_path, to test a second way a check can come back empty.

The three roles:

det_owner serves the requests and owns the tables. The case to detect.
det_app serves the requests, owns nothing, has normal read and write grants.
det_bare serves the requests, owns nothing, and has no grant at all on the tables. A role that was never fully provisioned.

The two queries

The check needs one thing from the application: the list of tenant tables. In a Symfony app that list already exists, in the Doctrine metadata of the entities you scope by tenant. The queries join that list to pg_catalog by name, with a LEFT JOIN:

-- Does the serving role own the tenant tables?
SELECT w.s || '.' || w.t                          AS tenant_table,
       (c.oid IS NOT NULL)                        AS seen_in_catalog,
       pg_get_userbyid(c.relowner)                AS owner,
       pg_get_userbyid(c.relowner) = current_user AS owned_by_me
FROM   (VALUES ('public','organization'),
               ('public','invoice'),
               ('archive','audit_log')) AS w(s, t)
LEFT   JOIN pg_catalog.pg_namespace n ON n.nspname = w.s
LEFT   JOIN pg_catalog.pg_class     c ON c.relnamespace = n.oid AND c.relname = w.t;

-- Is RLS enabled, and is it forced?
-- same FROM and joins, selecting c.relrowsecurity and c.relforcerowsecurity

The LEFT JOIN is not cosmetic. It turns "I cannot see this table" into a row with seen_in_catalog = false, which is a result you can act on, instead of a missing row, which is silence.

What they return

                                        join by name        to_regclass()                 information_schema.tables
det_owner  owns the tables              3 rows, owned=t     3 rows                        3 rows
det_app    owns nothing, DML grants     3 rows, owned=f     3 rows                        3 rows
det_bare   owns nothing, no grants      3 rows, exact       ERROR: permission denied      0 rows, no error
                                                            for schema archive

The first column is the answer to the question from the thread. pg_class and pg_namespace are readable by PUBLIC by default, so a role with no privilege at all on the tenant tables still reads their owner, relrowsecurity and relforcerowsecurity, exactly. Visibility of the catalog is not the problem.

The verdict, written as one query over the same join, has three outcomes and never two:

det_owner   WARNING: the serving role owns 3 tenant table(s) without FORCE
det_app     NOTHING TO REPORT
det_bare    NOTHING TO REPORT      (correct: it owns nothing, and it can see that)
fresh db    UNDETERMINED: 3 tenant table(s) not found in the catalog

The third outcome is the one that answers the original fear. "I could not find the tables" is not "nothing to report", and a fresh database where the migrations have not run yet gets UNDETERMINED, which is the true answer.

Route 1: the first query you would naturally write

The obvious way to list tables is information_schema.tables. For det_bare it returns zero rows, with no error. Its views only show what the current role has some privilege on.

In this particular case the verdict happens to be right, since det_bare owns nothing. That is exactly why it survives review. A check built on it cannot tell "there are no tenant tables here" from "I am not allowed to see them" from "the migrations never ran", so it loses the third outcome, and the third outcome was the point.

to_regclass() is the other tempting shortcut, and it fails the other way. Resolving a qualified name needs USAGE on the schema, so for archive.audit_log the whole query dies with permission denied for schema archive, taking down the answers for the two tables it could have read. That one is at least loud. The join by name does no resolution, and has neither problem.

A detour: the check that warns every install

Before the second route, a mistake I nearly made in the verdict. The condition "the serving role owns the table and FORCE is off" is true on every database where RLS was never enabled. I dropped RLS from the three tables and ran it as the owner:

naive    (owned AND NOT forced)             WARNING: the serving role owns 3 tenant table(s) without FORCE
fixed    (owned AND enabled AND NOT forced) NOTHING TO REPORT: no RLS on these tables

A project that does not use RLS at all would get a warning about a feature nobody asked for, on every run. A check that warns everyone warns no one. It should only speak when RLS is enabled and not forced.

Route 2: the connection, not the query

Now the one I cannot close. Open the connection as the owner, then step down to the serving role with SET ROLE, which is one way to get a non-owner role without a second set of credentials:

SET ROLE det_app;
current_user = det_app, session_user = det_owner
verdict: NOTHING TO REPORT

RESET ROLE;
current_user = det_owner
rows read from invoice with no tenant context set: 2 of 2

The check asks about current_user, and current_user is the serving role, which owns nothing. The answer is accurate and meaningless: anything running on that connection can RESET ROLE and is back to being the owner, and the owner bypasses a policy that is not forced. Two rows out of two, no context set.

Asking about session_user as well does catch it, all three tables come back as owned by the login role. So the check should look at both. But that only reduces the problem, it does not remove it: the check measures the connection it is run on. If you run it locally with one DATABASE_URL and deploy with another, it measured the wrong role, and nothing in its output tells you.

Where the check can live

This bench also settled where such a check cannot go:

Not before the migrations. On a fresh database it returns UNDETERMINED. Correct, and useless at that moment. It belongs after doctrine:migrations:migrate.
Not in a pre-install check that runs before the environment is configured. It needs a real connection with the production role.
Not without the application's list of tenant tables. Without it there is no LEFT JOIN, so no third outcome.

What this does not cover

Nothing was measured behind PgBouncer, or with a SET ROLE issued by a pooler rather than by the application. I also revoked SELECT on pg_class and pg_namespace from PUBLIC to test the edge: the check then fails with a permission error, which is the right way to fail. pg_tables still answers in that case, since a view runs with its owner's rights, but it does not expose FORCE, so it can answer the first question and not the second. I have not seen those grants revoked in production; the case is there to find the boundary, not to describe a real deployment.

Reproduce it

The bench is one bash script, and every query that matters is in this article. It creates the database and the three roles, runs every query above as each role, locks the catalog, computes the verdicts, does the step-down, disables RLS for the false positive, drops the tables for the fresh database case, and removes everything on the way out. Its labels are in French: the outputs above are translated, the values are not. I wrote it alongside ShipAnvil, a multi-tenant Symfony kit that scopes tenants with a Doctrine filter: here is what the source code licence contains and costs. To be clear about what that means here: the kit ships no RLS and no such check today. This is a measurement of the idea, not a feature announcement.

Thanks to @to21as for the distinction that started it: detecting is not imposing. It holds. The measurement just adds the condition: a check like this has to say what it could not see before it says anything.

Postgres RLS in Symfony: three green isolation tests, and the UPDATE that moves tenant 1's invoices into tenant 2's books

Eric Mollenthiel — Mon, 14 Sep 2026 15:06:17 +0000

Two articles ago I wrote that the Postgres role which runs your migrations bypasses every row-level security policy. Last week I wrote that with one tenant in the fixture, your isolation suite passes with no policy at all. Both came out of the same comment thread, and by the end of it we had three assertions that, together, cover every broken database I had been able to build.

Then Marco pointed out what he liked about the pair: it never leaves the enforcement boundary it is checking. So I went looking for the next place where a green suite means nothing, and it took one line of SQL to find it. All three assertions only read. None of them says a word about what a tenant can write.

Here is a database where tenant 1 can move every one of its invoices into tenant 2's books, in one statement, and every isolation test in this series is green on it.

The loud error that gets you there

You do not arrive at that database on purpose. You arrive at it by fixing an error.

Once a table has FORCE ROW LEVEL SECURITY, the owner is subject to the policy too. That is the correct setting, it is the whole point of the first article, and it has a consequence the first time you seed a fixture: the seeding connection is the owner, the policy reads current_setting('app.tenant_id'), nothing has set it, and Postgres refuses to insert.

no context, INSERT (1,1,100)   : ERROR:  new row violates row-level security policy for table "invoice"
context=1,  INSERT (1,1,100)   : ok
context=1,  INSERT (2,2,200)   : ERROR:  new row violates row-level security policy for table "invoice"

Even with the context set, the second tenant's row is refused, because you are inserting tenant 2's row while claiming to be tenant 1. My own bench hit this while I was writing the article: the seed step ran as the owner, under FORCE, with no context, and the first two scenarios ran on an empty table until I noticed.

The error is loud, it is correct, and it is annoying in exactly the place where people are in a hurry. The obvious repair is to relax the check:

CREATE POLICY tenant_isolation ON invoice
  USING      (tenant_id = current_setting('app.tenant_id', true)::int)
  WITH CHECK (true);

Reads are still filtered, the seed goes through, the suite is green. It is the same shape as the NULLIF trap from the previous article: a tempting fix that turns a loud failure into a silent one. And unlike NULLIF, this one is not a degraded mode. It is a hole.

Three policies, three assertions, four writes

Same table, same two rows, same FORCE, three shapes of policy. The three columns on the left are the assertions the thread built. Equality is the double run: the owner and the serving role return the same set. Scoped is the ordinary one: tenant 1 sees only its rows. Disjoint is Marco's: tenant 2 sees something, and none of it is tenant 1's. Then tenant 1, under its own context, attempts four writes aimed at tenant 2.

                            equality  scoped  disjoint | INSERT    INSERT..RETURNING  UPDATE..WHERE  UPDATE no WHERE
USING only                    GREEN    GREEN    GREEN  | refused       refused           refused        refused
USING + WITH CHECK (same)     GREEN    GREEN    GREEN  | refused       refused           refused        refused
USING + WITH CHECK (true)     GREEN    GREEN    GREEN  | ACCEPTED      refused           refused        ACCEPTED

The first two rows are the sound ones. When WITH CHECK is omitted, Postgres uses the USING expression for it, so "USING only" is not a shortcut, it is the correct policy written short. Every cross-tenant write is refused on both.

The bottom row is the one the seeding error pushes you towards. The same three assertions that caught every broken database in the previous article are green on it, and tenant 1 can file an invoice into tenant 2's books.

The two refusals on that row are not what they look like

WITH CHECK (true) accepts everything, so what is refusing UPDATE ... WHERE id = 1 and INSERT ... RETURNING id on that row?

Not the write policy. It is the USING expression of the read side, applied to the new row, and it only applies because the statement reads a column. Footnote [a] of the "Policies Applied by Command Type" table in CREATE POLICY says the SELECT policy is checked against the new row when read access is required to it, "for example, a WHERE or RETURNING clause that refers to columns from the relation". The plain INSERT does not read, so it passes. The same INSERT with RETURNING id reads, so it is refused. UPDATE ... WHERE id = 1 reads id, refused. UPDATE ... SET tenant_id = 2 with no WHERE reads nothing, accepted.

So on that database the write side is guarded by the read policy, by accident, and only while the statement happens to read something. Take the read away and there is nothing left:

before : tenant 1 = [1], tenant 2 = [2]
tenant 1 runs, under its own context: UPDATE invoice SET tenant_id = 2
after  : tenant 1 = [], tenant 2 = [1,2]

USING still filters on the way in, so tenant 1 only touches its own rows. Then it hands all of them to tenant 2. The tenant that lost its data cannot see where it went, and the tenant that received it never asked for it. No error, no log line, and three green assertions.

Two smaller results from the same bench, for completeness. DELETE FROM invoice with no WHERE under tenant 1 deletes tenant 1's rows only: USING filters the existing rows, and a DELETE has no new row to check. UPDATE invoice SET amount = 0 with no WHERE is likewise confined to tenant 1. The hole is specifically a write that changes which tenant a row belongs to, or inserts a row under another tenant's label, on a policy whose WITH CHECK no longer looks at tenant_id.

The fourth assertion is one line, and it belongs in the same test

Equality and disjointness say the boundary separates what is already in the table. Neither says anything about what a tenant can put there. The missing assertion is: as tenant 1, attempt a write labelled tenant 2, and assert that it raises.

function assertCrossTenantWriteRaises(Connection $c, int $asTenant, int $towardsTenant): void
{
    $c->beginTransaction();
    try {
        $c->executeStatement('SELECT set_config(?, ?, true)', ['app.tenant_id', (string) $asTenant]);
        $c->executeStatement(
            'INSERT INTO invoice (id, tenant_id, amount) VALUES (?, ?, ?)',
            [999, $towardsTenant, 1]
        );
        self::fail('a write labelled with another tenant went through');
    } catch (DriverException $e) {
        self::assertSame('42501', $e->getSQLState());
    } finally {
        $c->rollBack();
    }
}

The SQLSTATE matters. 42501 is insufficient_privilege, which is what a policy violation raises. Catching any exception would let a typo in the statement pass for a refusal.

Run against the three policies:

USING only               GREEN (42501 raised)
USING + WITH CHECK       GREEN (42501 raised)
USING + WITH CHECK(true) RED   (insert accepted)

Red in exactly the row the other three sleep through. With the four assertions together, I no longer have a broken database that the suite stays green on. I had that sentence about three assertions a week ago, so take it for what it is: the next comment thread may well find the fifth.

Seed with the context, not around it

The honest fix for the seeding error is not to weaken the policy, it is to seed the way the application writes: set the tenant context, insert that tenant's rows, set the next one. It is the same set_config(?, ?, true) call the tests already use, inside the same transaction. A fixture that goes through the policy is also a fixture that proves the policy accepts legitimate writes, which is the positive half of the claim and worth having on its own.

If you seed with a superuser or a BYPASSRLS role instead, it works, and it puts the seed outside the boundary again. That is fine for a fixture as long as the assertions themselves stay inside it, which is what the previous article was about.

Reproduce it

Two bash scripts and three PHP files. They create a throwaway database and two roles, build the table under each policy, run the three read assertions and the four writes under the serving connection, show the damage from the unguarded UPDATE, run the fourth assertion, and drop everything on the way out. PostgreSQL 18.3, PHP 8.5.7, Doctrine DBAL. Nothing in them is specific to my schema, and I would rather you ran them against yours than believed my output. I wrote them alongside ShipAnvil, a multi-tenant Symfony kit that scopes tenants with a Doctrine filter and ships no RLS of its own. There is no product in them either: a table called invoice, two rows, and a policy with a hole in it.

Thanks to Marco for the sentence that started this: the pair stays inside the boundary. It does. It also only reads. If you are running RLS in a Symfony app, the cheapest thing you can do this week is open your policies and look at what WITH CHECK says. If one of them says true, you already know what your isolation suite cannot see.

Postgres RLS in Symfony: with one tenant in the fixture, your isolation suite passes with no policy at all

Eric Mollenthiel — Mon, 31 Aug 2026 08:33:49 +0000

Ten days ago I wrote that the Postgres role which runs your migrations bypasses every row-level security policy you wrote. Mads Hansen replied with the obvious next step, and it was better than the article: run the same cross-tenant query suite twice, once as the serving role and once as the owner role, and compare.

I did. It works, and I published the assertion. Then Marco took it apart with one question: what happens if you remove the violating state from the fixture? I measured that too, and it caught my own advice out. Equality is green in four databases out of five, and three of them are broken.

So this is both halves. If you only take the first one home, you get a test that is green on a database with row-level security switched off.

The invariant is not "the owner run must fail"

My first instinct was to assert that the owner run leaks: it sees rows from other tenants, so the assertion is assertNotSame. That assertion is wrong, and it goes red on the day someone applies the correct fix.

ENABLE ROW LEVEL SECURITY leaves the table owner exempt. FORCE ROW LEVEL SECURITY does not. After FORCE, the owner sees exactly what the serving role sees. Measured on PostgreSQL 18.3, same fixture, same query:

### 1. ENABLE only: the owner ignores the policy
tenant 1 : serving=[1] owner=[1,2] DIVERGENT  <-- leak
tenant 2 : serving=[2] owner=[1,2] DIVERGENT  <-- leak

### 2. After FORCE ROW LEVEL SECURITY: both runs return the same set
tenant 1 : serving=[1] owner=[1] IDENTICAL
tenant 2 : serving=[2] owner=[2] IDENTICAL

So the invariant that survives both worlds is: both runs return the same set. Not "the owner run fails". Write it as equality and it stays green when the schema is fixed, red when someone drops FORCE in a migration.

That is the assertion I gave in the thread, and it is where I would have stopped.

Equality alone is green in three databases that are broken

Marco's reply is the sentence I would keep from the whole exchange: the fixture is part of the security claim, not just test data. And its consequence, which is the part that made me go back to psql: if removing the violating state doesn't make the test fail, then the test was never actually proving the invariant.

So I built the same table five different ways and ran three assertions side by side. Tenant 1 is the one being queried. Equality is the double run above. Scoped is the ordinary one everybody writes: the serving role returns only its own rows. Disjoint is Marco's, made executable: set the context to the second tenant, assert that set is non-empty and does not intersect the first.

                            equality  scoped  disjoint
2 tenants, no RLS at all      GREEN     RED     RED
2 tenants, ENABLE only        RED       GREEN   GREEN
2 tenants, FORCE              GREEN     GREEN   GREEN
1 tenant,  ENABLE only        GREEN     GREEN   RED
1 tenant,  no RLS at all      GREEN     GREEN   RED

Only one row of five is a sound database. Read the columns rather than the rows.

Equality is green in four rows and three of them are broken. Two runs that both return everything are still equal, so it never notices the world where there is no policy at all. It is red in exactly one row: the one my article was about.

Scoped does not rescue it. Look at the bottom two rows: with a single organisation in the fixture, the serving role returns its one row whether the policy applies, or is inert because the app account owns the table, or does not exist at all. Both assertions are green, and one of those databases has the owner bypass sitting in it waiting for a second customer to sign up.

That is the headline, and it is worth saying without the table: if your fixture has one tenant, your tenant-isolation test passes against a database with no row-level security on it. The failure direction here is always too many rows, never zero, so a fixture that contains nothing to refuse cannot tell a working boundary from an absent one.

Only the disjointness column notices that the fixture stopped being a violation. It is red in the three broken rows equality sleeps through, green in the sound one, and between them the pair covers all four broken worlds.

Disjointness has to stay inside the boundary it is checking

The part I did not expect was how to write it without reaching for privilege.

The obvious way to assert "there is still a second tenant in that table" is to go look with a connection that can see everything. Under FORCE there is no such connection left, which is the whole point of FORCE, and grabbing a superuser to check the fixture puts the check back outside the boundary you are trying to prove. You would be proving the policy from outside the policy.

Querying as the second tenant is what stays inside it: same role, same policy, same request-scoped setting, nothing the application could not do itself. If tenant 2 comes back empty, the fixture has gone stale and the negative control is gone. If it comes back overlapping tenant 1, the boundary is not separating anything.

function visibleIds(Connection $c, int $tenantId): array
{
    $c->beginTransaction();
    try {
        // set_config(..., true) is SET LOCAL, but it takes a bound parameter.
        $c->executeStatement('SELECT set_config(?, ?, true)', ['app.tenant_id', (string) $tenantId]);
        $ids = $c->fetchFirstColumn('SELECT id FROM invoice ORDER BY id');
    } finally {
        $c->rollBack();
    }

    return array_map('intval', $ids);
}

$servingA = visibleIds($serving, 1);
$ownerA   = visibleIds($owner,   1);
$servingB = visibleIds($serving, 2);

// Nobody is above the policy.
self::assertSame($servingA, $ownerA);

// There is a policy, and the fixture still contains something for it to refuse.
self::assertNotSame([], $servingB);
self::assertSame([], array_intersect($servingA, $servingB));

That set_config call is worth a line of its own. SET LOCAL app.tenant_id = ? is not parameterisable: SET takes a literal, so you end up interpolating a tenant id into SQL, in the one place where you least want to. set_config(name, value, is_local) is the same thing as a function call, and DBAL binds it like any other query.

And the run prints the ids rather than a count on purpose. serving=[1] owner=[1,2] says something. 1 !== 2 says the same thing with much less to go on when it fails in CI at 2am.

The two ways "no tenant context" fails, and they are not alike

fresh connection, no context     : is_null=yes, rows=0            (silent)
reused connection, no context    : SQLSTATE[22P02] invalid input syntax for type integer: ""   (loud)

A connection that never had the setting returns NULL from current_setting('app.tenant_id', true), the policy matches nothing, and you get zero rows in silence. A connection that had it set with SET LOCAL inside a transaction gets the empty string back once that transaction ends, not NULL, and the cast to int raises 22P02.

The tempting fix is to make the policy tolerant:

USING (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::int)

Measured: it works, and it is a trap. It turns the loud failure into the silent one. Zero rows, no error, on a connection that just lost its tenant context. If you have to choose, choose the version that raises: a query that explodes is an incident, a query that quietly returns nothing is a customer email three weeks later.

The leak that hides under PHP-FPM

Last one, and it is the reason any of this matters outside the test suite. SET app.tenant_id = '2' without LOCAL, in a transaction that commits, survives the transaction. Not the request: the connection.

BEGIN; SET app.tenant_id='2'; SELECT count(*) FROM invoice; COMMIT;
SELECT current_setting('app.tenant_id', true), count(*) FROM invoice;
-- still_here | count
--  2         |     1

A rollback undoes it, a commit does not. Under PHP-FPM this is invisible, because the connection dies with the request and the next one starts clean. Put PgBouncer in transaction mode in front of it, or run the same code in a Messenger worker that holds a connection for hours, and the next transaction on that connection reads the previous tenant. The LOCAL keyword is the entire difference, and no test that runs one request at a time will ever tell you it is missing.

Reproduce it

Two bash scripts and two PHP files: they create a throwaway database and two roles, build the table in each of the five configurations, run the assertions under both connections, and drop everything on the way out. PostgreSQL 18.3, PHP 8.5.7, Doctrine DBAL. Nothing in them is specific to my schema, and I would rather you ran them against yours than believed my output. They came out of the multi-tenant kit I work on, ShipAnvil, but there is no product in them: it is a table called invoice with two rows.

Thanks to Mads Hansen for the double run, and to Marco for the question that showed the double run was half an answer. If you are running RLS in a Symfony app, the cheapest thing you can do this week is open your isolation test and count the tenants in its fixture.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Row-level security in Symfony: the role that ran your migrations bypasses every policy you wrote

Eric Mollenthiel — Fri, 21 Aug 2026 16:38:18 +0000

A comment on my last article was better than the article. The subject was single-database multi-tenancy, and @to21as argued that the predicate should not live in the ORM at all: put it in Postgres as a row-level security policy, and a Messenger worker, a line of native SQL and an ad-hoc psql session all get the same WHERE clause whether anyone remembered it or not. That is correct, and it is the strongest version of the case against doing it in Doctrine. It closes four of the five holes I had just finished listing.

Then came the warning: their two RLS bugs had both been invisible in tests, because the test connection was a superuser and superusers bypass RLS.

The trap is wider than superusers, and the wider version is the one that lands on a Symfony deployment. A plain role that merely owns the table bypasses that table's policies too. Not a superuser. No BYPASSRLS. Just the owner. And the role that owns your tables is, in almost every Symfony deployment I have read, the same role your application connects with.

Everything below was measured on PostgreSQL 18.3, on a throwaway database, and every command is in the article so you can disagree with the result rather than with me.

The setup, which is the one you would write

CREATE ROLE app LOGIN PASSWORD '...';
CREATE DATABASE app_db OWNER app;

That second line is not a strawman. It is what my own deploy guide says, and it is what makes doctrine:migrations:migrate work without a privilege dance, which is why it tends to be what a deploy guide says. Then a migration does the usual:

CREATE TABLE invoice (
    id              int PRIMARY KEY,
    organization_id int NOT NULL,
    total_cents     int NOT NULL
);

ALTER TABLE invoice ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoice
    USING (organization_id = current_setting('app.organization_id', true)::int);

RLS is on. The policy is right. The role is not a superuser and has no BYPASSRLS:

 current_user | is_superuser | has_bypassrls | table_owner | rls_enabled | rls_forced
--------------+--------------+---------------+-------------+-------------+------------
 app          | f            | f             | app         | t           | f

Two invoices in the table, one for each of two organizations. The application connects as app, sets nothing, and asks:

SELECT count(*) FROM invoice;

2. No error, no warning, no log line. Every tenant's rows, through a policy that is enabled and correct.

One line changes the answer

ALTER TABLE invoice FORCE ROW LEVEL SECURITY;

Same role, same connection, same query. 0. Set the tenant and you get exactly the one row you should:

SET app.organization_id = '2';
SELECT count(*) FROM invoice;   -- 1

The documentation is not hiding this. PostgreSQL 18, section 5.9, read on 2026-08-21:

Superusers and roles with the BYPASSRLS attribute always bypass the row security system when accessing a table. Table owners normally bypass row security as well, though a table owner can choose to be subject to row security with ALTER TABLE ... FORCE ROW LEVEL SECURITY.

"Normally bypass" is doing a lot of work in a sentence most of us read once, while looking for the syntax of CREATE POLICY.

Why a Symfony project walks into this and a test suite does not catch it

Three things have to line up, and a standard deployment lines up all three.

Doctrine creates the tables, under the credentials in DATABASE_URL. There is one connection string in a Symfony app. It runs the migrations and it serves the requests, so the serving role is the owning role. Nothing in the framework, in Doctrine or in Postgres considers that unusual, because it is not unusual. It is the default shape.

The failure direction is extra rows, not missing ones. A broken filter that returns nothing gets noticed in about four seconds. A filter that returns everything looks like a working page. Under RLS with an owner role you are not in a degraded state, you are in the state you were in before you wrote any of it.

Your fixtures make the two indistinguishable. A functional test that seeds one organization, logs a user in and asserts it sees its own row passes identically whether the policy applies or is inert. The assertion that catches this is the negative one: seed a second organization, and assert the first user cannot count it. If your suite has only the positive assertion, the day the policy stops applying is a day nothing turns red.

Which is how you ship a database with row-level security enabled on every tenant table, policies written and reviewed, and not one of them in force.

Two fixes, and I measured both

`FORCE ROW LEVEL SECURITY`

Add it to the same migration that enables RLS, next to the policy:

ALTER TABLE invoice ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoice FORCE  ROW LEVEL SECURITY;

Cheap, local, no infrastructure request. The catch is that it is per table and there is no default: the next tenant table someone adds in six months comes back with relforcerowsecurity = false and a policy that does nothing. This is a guarantee that decays.

A serving role that does not own anything

CREATE ROLE app_migrate LOGIN PASSWORD '...';   -- owns the schema, runs migrations
CREATE ROLE app_serve   LOGIN PASSWORD '...';   -- serves requests, owns nothing
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_serve;

Connecting as app_serve, with no FORCE anywhere and nothing set, the same two tables return 0 of 2. Set the tenant inside a transaction and you get 1. The bypass never existed, because ownership never existed.

This is the version that does not decay, and it is the version that costs you something real: two connection strings, a migration step that runs as a different user than the app, default privileges to get right for future tables, and a deploy document that now has a paragraph in it. If you are shipping a repo that other people deploy on infrastructure you will never see, that paragraph is a support cost forever. That trade is the actual decision, and it is not a database question.

The guard that survives the next table

Whichever you pick, this belongs in your suite, not in a runbook:

SELECT c.relname, c.relrowsecurity AS enabled, c.relforcerowsecurity AS forced
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_attribute a ON a.attrelid = c.oid
                   AND a.attname = 'organization_id'
                   AND NOT a.attisdropped
WHERE c.relkind = 'r' AND n.nspname = 'public';

Every table with an organization_id column, and whether its policies actually apply. Assert that the list of unprotected ones is empty and the test names the new table for you the day someone adds it. On my demo database it correctly reported one table protected and one not, which is the only reason I trust the rest of this article.

And once RLS does apply, the setting has two ways to be missing

The policy reads current_setting('app.organization_id', true). There are two different empty states behind that call, they fail differently, and only one of them is loud.

SET LOCAL outside a transaction block does nothing. Postgres raises a warning, not an error, and PDO does not turn warnings into exceptions:

$pdo->exec("SET LOCAL app.organization_id = '2'");  // no exception
$pdo->query("SELECT current_setting('app.organization_id', true)")->fetchColumn();
// string(0) ""

A Symfony request has no open transaction until something flushes, so a kernel.request listener that issues SET LOCAL is issuing it into nothing. Scoping a request with RLS means an explicit transaction wrapped around the whole request, which is a much bigger architectural commitment than the two lines it looks like.

Then the two empty states diverge, and this is worth knowing before it happens in production:

never set: current_setting(..., true) returns NULL, NULL::int is NULL, the comparison is NULL, you get zero rows and no error. A blank dashboard.
set, then discarded: the setting exists and is the empty string, and ''::int throws SQLSTATE[22P02] invalid input syntax for type integer: "". A 500 on every query against a tenant table.

Same missing tenant, one silent and one fatal, decided by whether that variable was ever touched on the connection. Write the policy so you choose which one you get, rather than finding out.

And the reason it has to be SET LOCAL rather than SET: a plain SET outlives the transaction. Measured on one connection, two consecutive transactions:

-- request A, plain SET, tenant 2
   rows: 1
-- request B on the same connection, sets nothing
   current_setting: '2'
   rows it can see: 1

Request B never identified itself and is reading tenant 2. With persistent connections or a pooler in transaction mode, request B is a different customer.

What I would keep

RLS is the stronger mechanism. The comment that started this was right that it closes the holes an ORM-level filter leaves open, and I said so at the time. What I would not do is adopt it on the strength of ENABLE ROW LEVEL SECURITY and a policy that reviews well, because that pair is exactly the configuration I measured returning every row in the table.

Three things, if you are reaching for it this week. Check relforcerowsecurity, not relrowsecurity, because the first is the one that means anything when your app owns its tables. Decide between FORCE and a non-owning serving role on deployment cost, not on elegance, since both were airtight when measured. And test the negative case, because the positive one passes with the policy switched off.

I maintain ShipAnvil, a Symfony 7.4 LTS SaaS starter. Its tenancy layer is the Doctrine filter from the previous article, not this, and the paragraph about deployment cost is why. The article stands on its own. If your production database has RLS enabled today, the pg_class query above takes ten seconds and I would run it before finishing this page.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Single-database multi-tenancy in Symfony: a 31-line Doctrine filter, and the five places it never runs

Eric Mollenthiel — Wed, 19 Aug 2026 15:51:43 +0000

Single-database multi-tenancy is the cheapest kind: one schema, one connection, an organization_id column on every tenant-owned table. The whole design rests on one promise, and it is a promise about forgetting: no developer on the team will ever have to remember to write WHERE organization_id = ?, because forgetting it once leaks another customer's data.

Doctrine has had the tool for this for years. It is a SQLFilter, it is about thirty lines, and almost every article about it stops at the happy path. The interesting part is not the filter. It is the map of the places where it is simply not there, because that map is what you actually have to defend.

Everything below is read from Doctrine ORM 3.6.7 and from a suite that runs on every commit.

The filter

final class OrganizationFilter extends SQLFilter
{
    public const string NAME = 'organization';
    public const string PARAMETER = 'organization_id';

    public function addFilterConstraint(ClassMetadata $targetEntity, string $targetTableAlias): string
    {
        if (!$targetEntity->getReflectionClass()->implementsInterface(OrganizationOwnedInterface::class)) {
            return '';
        }

        return \sprintf('%s.organization_id = %s', $targetTableAlias, $this->getParameter(self::PARAMETER));
    }
}

OrganizationOwnedInterface is a marker with one method, getOrganization(). An entity opts into tenancy by implementing it, and that is the entire public API of the mechanism. No attribute to remember, no base class to extend, no trait whose absence is invisible in a diff.

The filter is declared in doctrine.yaml with enabled: false. That is deliberate, and it is the first design decision worth arguing about: a filter that is on by default in the container is on in your fixtures, in your migrations, in your data-repair scripts, and it will bite you at three in the morning. It gets turned on by the layer that knows who is asking.

The layer that knows who is asking

public static function getSubscribedEvents(): array
{
    // Right after the firewall (priority 8) so the user is available.
    return [KernelEvents::REQUEST => ['onKernelRequest', 7]];
}

public function onKernelRequest(RequestEvent $event): void
{
    if (!$event->isMainRequest()) {
        return;
    }

    if (str_starts_with($event->getRequest()->getPathInfo(), '/admin')) {
        return;
    }

    $organization = $this->organizationContext->getOrganization();

    if (null === $organization) {
        return;
    }

    $this->entityManager
        ->getFilters()
        ->enable(OrganizationFilter::NAME)
        ->setParameter(OrganizationFilter::PARAMETER, (string) $organization->getId());
}

Priority 7 is not a magic number. Symfony's Firewall listener subscribes to kernel.request at priority 8, so 7 is the first slot where Security::getUser() is populated. Higher and you get no user and therefore no filter at all, which is the worst possible failure mode, because the page still renders.

That is the whole mechanism. Now the useful part.

Place 1: the console, and every Messenger worker

There is no kernel.request in a CLI process. Your commands, your cron jobs and your Messenger consumers therefore run with the filter off, seeing every tenant's rows.

This is correct behaviour and you want it: a nightly billing command has to iterate over all organizations. But it means the guarantee "tenant data is invisible by default" is a guarantee about HTTP, not about your application. Every command that touches tenant-owned entities has to scope itself explicitly, and there is no compiler to remind you.

The honest framing is: the filter is a safety net under your controllers. Under your workers there is no net, and pretending otherwise is how a support script mails the wrong invoice to the wrong customer.

Place 2: your own back office, on purpose

An admin panel exists precisely to look across tenants. Filtering it would make the metrics wrong and the CRUD useless, so /admin is exempted by path.

The trade is that a path prefix now carries a security consequence, and path prefixes are easy to change. It only holds because the same prefix is locked to ROLE_ADMIN in access_control. If you copy this pattern, copy both halves, and treat the exemption list as security-critical code rather than as configuration.

Place 3: `find()` when the entity is already in the identity map

// EntityManager::find(), doctrine/orm 3.6.7
$entity = $unitOfWork->tryGetById($sortedId, $class->rootEntityName);

find() returns from the identity map before any SQL is generated. If an entity belonging to another organization was loaded earlier in the same request, by a fixture, by a cascade, by a getReference() that got initialized, then find() hands it back and no filter is consulted, because no query happens.

The same applies to getReference() itself, which builds a proxy from an id without touching the database at all. Passing a user-supplied id to getReference() and trusting the filter to reject it does nothing: the proxy is returned, and it only fails much later, when something initializes it.

Practical rule: a filter protects queries, not object identity. Authorization on an id that came from the outside is still authorization. Keep your voters.

Place 4: DBAL, and every line of native SQL

Filters are a DQL concern. $connection->executeQuery() and createNativeQuery() never see them. This is obvious once stated, and it is where the leaks actually happen, because native SQL is exactly what people reach for on the reporting and export screens, which are exactly the screens that show a lot of rows at once.

Place 5: joined inheritance, when the column is not on the root table

This one is silent, and it is the reason to read the ORM source rather than the documentation.

// SqlWalker::generateFilterConditionSQL(), doctrine/orm 3.6.7
case ClassMetadata::INHERITANCE_TYPE_JOINED:
    // The classes in the inheritance will be added to the query one by one,
    // but only the root node is getting filtered
    if ($targetEntity->name !== $targetEntity->rootEntityName) {
        return '';
    }

With JOINED inheritance, Doctrine only ever offers the root entity to your filter. So if your abstract root does not implement the tenancy interface and each concrete subclass does, the subclass is skipped by Doctrine and the root is skipped by your own implementsInterface() check. Two correct-looking guards, and the result is no WHERE clause at all.

The fix is a modelling rule, not a code change: in a joined hierarchy, organization_id and the marker interface belong to the root entity. Worth an architecture test if your domain uses inheritance.

And one place it does run, where most people assume it does not

The folklore says Doctrine filters only apply to SELECT. That is false in ORM 3, and it is easy to check: walkUpdateStatement() and walkDeleteStatement() both call walkWhereClause(), which is exactly where filters are injected. Here is the SQL Doctrine actually generated for me, with the filter enabled:

-- DQL: DELETE FROM SampleNote n
DELETE FROM sample_notes WHERE (sample_notes.organization_id = '...')

-- DQL: UPDATE SampleNote n SET n.title = :t
UPDATE sample_notes SET title = ? WHERE (sample_notes.organization_id = '...')

Bulk DQL statements are scoped. Note the table name in place of an alias, since useSqlTableAliases is false for those statements. Good news, but do not let it lull you: this is the ORM's DQL path only, and place 4 still stands one line away.

Proving it, rather than believing it

An isolation guarantee that is not tested is a comment. The check is short, and the part that matters is the assertion on the filter itself, the one that fails loudly the day someone "simplifies" the subscriber:

$client->loginUser($user);
$client->request('GET', '/dashboard');

self::assertTrue($entityManager->getFilters()->isEnabled(OrganizationFilter::NAME));

$notes = $entityManager->getRepository(SampleNote::class)->findAll();
self::assertCount(1, $notes);
self::assertSame('Mine', $notes[0]->getTitle());

Plus its mirror image, that an anonymous request leaves the filter off, which is what catches a firewall-priority regression before your customers do.

Two organizations, one row each, one authenticated request. It runs in under a second, and it is the only reason anyone should believe the paragraph at the top of this article.

What I would keep

Three sentences, if you are building this today.

The filter belongs off in the container and on at the edge, because the layer that knows the tenant is the only layer entitled to turn it on. The marker interface belongs on the root entity, and an architecture test should say so. And the filter is a net under HTTP only, so every command, every consumer and every line of native SQL is code you have to read with tenancy in mind.

I maintain ShipAnvil, a Symfony 7.4 LTS SaaS starter, and this is the tenancy layer it ships, isolation tests included. The article stands on its own, though. If you find a sixth hole, I would genuinely like to hear about it.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Every no-code builder generates code. I shipped an interpreter instead.

Eric Mollenthiel — Sat, 15 Aug 2026 13:00:20 +0000

Every no-code builder I have used ends the same way: you drag boxes around, you press
Save, and somewhere a template engine writes source code you are now responsible for.

I spent a few months building a plugin builder for Minecraft servers, and the obvious
version of it generates Java. Blocks in, .java out, Gradle, a jar you download. I got
close enough to that design to see where it ends, then threw it away and wrote an
interpreter instead.

This is what that decision actually costs and actually buys, with the parts that only
became obvious after the engine existed.

The domain, in four lines

A Minecraft server plugin is a jar built against the Paper API. It hooks events (a player
joins, a block breaks, someone types in chat) and reacts.

Twice a year Minecraft ships a version, the API moves, and every plugin on every server
breaks at once. Plugin authors spend their lives recompiling. Server owners spend theirs
waiting. Fifteen years of this, and it is the single loudest complaint in the ecosystem.

That release cycle is not a detail of my domain. It is the thing that decides the
architecture.

Why generating Java is the trap

Generated code looks free at the design stage. You already know the shape of the output,
templates are easy, and the result is a normal plugin that behaves like every other plugin
on the server. The build is a solved problem.

Then you write down what happens on the day the API moves.

Every jar you have ever generated is frozen. The generator can be fixed in an afternoon,
but the fix reaches nobody: the broken code is already sitting in other people's server
directories. To ship it you have to regenerate and recompile every plugin of every user,
which means you need the original inputs of all of them, a build farm, a queue, and a
migration story for the ones whose regenerated output no longer compiles. A bug in a
template becomes an outage with a per-customer fan-out.

And that is the good day. On the bad day you are compiling and executing generated code in
production, which means a JDK, Gradle, a worker pool and a cache in the serving path, and
an attack surface shaped like "arbitrary Java, from the internet, run on a game server".
Minecraft in particular had a real supply chain attack in 2023 (fractureiser), spread
through plugin jars. Becoming another distribution channel for opaque bytecode was not a
neutral choice.

What I shipped instead

The studio produces a versioned JSON spec: trigger, conditions, actions. One hand-written
Paper plugin, the runtime, reads specs and executes them. Nothing generates Java anywhere.

A complete plugin:

{
  "specVersion": 1,
  "name": "Welcome",
  "rules": [{
    "name": "Welcome message",
    "trigger": { "type": "player.join" },
    "conditions": [
      { "type": "player.has_permission", "params": { "permission": "nimblock.vip" } }
    ],
    "actions": [
      { "type": "player.send_message", "params": { "message": "&6Welcome {player}!" } }
    ]
  }]
}

Saving that writes a row. Installing it drops a file in the server volume and hot reloads.
No build step exists to be slow, so nothing has to be made fast.

The comparison that decided it:

	Generate and compile	Interpret a spec
Save a plugin	a Gradle build, tens of seconds	a database write
Install on a running server	rebuild, redeploy, restart	drop the JSON, hot reload
Production infrastructure	JDK, Gradle, cache, workers, queue	none
Attack surface	compiling and running generated code	closed grammar, no arbitrary Java
Fix an engine bug	recompile every plugin of every user	publish one jar
Minecraft ships a version	every generated jar is broken	the runtime absorbs it once

The last row is the whole product. When the API moves, I fix one plugin, everyone's rules
keep running, and a spec written today should still run in three years untouched.

The part I did not see coming: the grammar becomes data

Here is the second-order effect, and it turned out to matter more than the build times.

When the grammar is a data file instead of a code generator, it can be the single source of
truth for both sides of the system. Mine is one catalogue-1.json: 9 triggers, 11
conditions, 14 actions. The JSON Schema is derived from it. The PHP validator in the studio
reads it. The Java engine reads the same file, copied into the jar at build time.

That buys two things a code generator cannot have.

Nothing can be offered and not implemented. The worst possible bug in a builder like
this is silent: an action the editor accepts, that nothing executes. The user places it,
the panel says fine, and nothing happens in game with no message anywhere. So the runtime
has a test that compares the catalogue to the handler registry in both directions:

@Test
void everyActionHasAHandler() {
    assertEquals(new TreeSet<>(catalogue.actionIds()), new TreeSet<>(new Actions(null).ids()));
}

Nothing in the catalogue without a handler, nothing handled outside the catalogue. With
generated code that test does not exist, because there is no registry to compare against:
you would be diffing templates.

The catalogue can carry a type system. Each trigger declares what it provides, each
action declares what it requires:

{ "id": "schedule.repeat", "context": [] }
{ "id": "player.heal",     "requires": ["player"] }
{ "id": "cancel_event",    "requires": ["cancellable"] }

So "heal the player" under "every N seconds" is refused as you write it, not at runtime,
because that trigger provides no player. cancel_event only exists under a cancellable
trigger. A typo'd {palyer} is rejected instead of landing in someone's chat as literal
text. That is roughly a type checker, expressed in a data file, and it exists only because
the grammar is data rather than a template.

Third rule, less about types and more about failure modes: a spec is accepted or rejected
as a whole. A protection plugin that loaded half its rules would fail silently in game,
in the worst way, so it does not load half.

The bill

An interpreter is not free, and the price is paid by the user, not by me.

The grammar is closed. Whatever is not in those 9 triggers, 11 conditions and 14 actions is
impossible, not "on the roadmap". Conditions do not nest either: all / any plus a not
per condition, no boolean tree. That last one is a genuine v1 limitation rather than a
principled stand, and it has an ugly reason: nested booleans draw badly as blocks.

If you need a guild system with its own database and its own GUI, this is the wrong tool
and it always will be. If you need "when a player joins for the first time, give them a kit
and announce it", it is two minutes. Knowing which side of that line you are on before you
invest is worth more than a longer feature list, so the full grammar is a public page and
you do not need an account to read it.

The escape hatch is a single "run as console" action, with exactly the power of the server
console and no more.

Three things the interpreter forced me to get right

Command registration is not hot. Paper only accepts new command names during its
COMMANDS lifecycle event, so a rule that declares a new command exists only after a
restart, while everything else in the same spec is live immediately. Rather than guess, the
agent records what Paper actually registered at boot; the difference with what the
installed specs declare is the pending list the panel shows. Same field left null tells
me a server predates the studio, so a reload would only produce a baffling "unknown
command" and the panel asks for a restart instead.

Cancellation is applied before the rule's actions, not after. For an ordinary rule the
order is unobservable. But chat arrives on another thread, and the remaining actions have
to hop back to the main thread, which is far too late to cancel anything. Applying it first
is the only version where chat moderation rules work at all.

A failing action stops its rule, never the server. Unknown item name, deleted world, a
numeric comparison on text: those are spec mistakes. They are worth one line in the console
and nothing more.

The obvious objection

"Fine, but my server is not hosted by you."

Right, and this is the part where the design pays off again rather than the part where it
falls apart: an export does not need a JDK either. The runtime jar is already compiled, so
exporting is injecting the specs as resources, rewriting plugin.yml, and rezipping.
ZipArchive in PHP, on the order of a hundred milliseconds, no build server anywhere. One
jar per account containing all of its specs, never one jar per plugin, so installing two of
them on the same external server cannot collide.

To be straight with you: that is designed and costed, not shipped. It is the next batch. I
am saying it here because it is the standard objection to a hosted builder, and because
"the escape route is cheap" is a consequence of the interpreter, not a promise bolted on
afterwards.

Where it is

It is live and free. The stack is Symfony 8 and PostgreSQL 18 on a single box, Paper
servers in rootless Podman containers, one network per server, filtered egress. The machine
holds twelve 1 GB servers, so there are twelve slots, which is a hardware limit rather than
a growth-hacking number.

The full grammar, every trigger, condition and action, generated from the same file the engine reads: https://nimblock.com/en/grammar
The studio, with a hosted Paper 26.1.2 server to try it on: https://nimblock.com/en

What I want back is not signups. It is the list of things you tried to express and could
not, because that list is what decides whether the closed grammar was the right call or
just the easy one.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Your storage format is the one thing you cannot refactor

Eric Mollenthiel — Sat, 15 Aug 2026 09:52:30 +0000

Ten days ago I published a post about encrypting personal data at rest in Symfony. A reader, Mads Hansen, left a comment that did not argue with the cryptography at all. It argued with seven characters that were not there.

The type I had shipped told encrypted rows from legacy plaintext rows by looking at the first byte: a { or a [ meant "this row predates encryption, hand it back as JSON". His objection, compressed: that makes the storage format ambiguous forever, and the ambiguity is a security property, not a cosmetic one, because a row that merely looks like JSON opts out of decryption no matter who wrote it.

He was right, and fixing it cost about eighty lines including tests. But the reason I am writing a second post rather than editing the first one is that the bug was not really about encryption. It was about a rule I had followed everywhere else in that codebase and broken here, and it is the one rule of software design I would keep if I had to throw away all the others:

everything you write can be refactored later, except the format of the bytes you have already stored.

Code is soft, storage is not

We say "software" and mean it. A class name is a rename away from being better. A bad abstraction survives until someone has an afternoon. Even a database schema, which feels heavy, is genuinely malleable: a column is added, backfilled, and dropped, and the tooling for that has been boring and reliable for twenty years.

Formats are different in kind, not in degree, and it took me an embarrassing number of years to feel the difference in my hands rather than know it as a maxim. A format is not code you own. It is an agreement between the process that wrote a value and every process that will ever read it, including the ones running a version of your code that no longer exists, on rows written by a colleague who left, in a database restored from a backup taken before the decision you are about to make.

You cannot change one side of an agreement unilaterally. What you can do is read the old shape and write the new one, which is exactly what a migration is, and which is exactly what requires you to be able to tell the two apart. That last part is the whole game.

Sniffing is the tax you pay for skipping the version

When a stored value carries no marker, the only way to know what it is, is to look at it and guess. Every codebase has these, and once you learn to see them they are everywhere:

if ($v[0] === '{') then it is JSON, otherwise it is PHP serialize() output.
if unserialize() throws, fall back to json_decode().
if the first two bytes are 0x1f 0x8b, it is gzipped, otherwise it is raw.
if the string is 32 hexadecimal characters, it is the old token format.
if the value is base64-decodable, it is the encrypted one.

Each of these works. That is precisely the problem: they work well enough that nobody replaces them, and each one quietly promotes an accident of the payload into part of the contract. The last example is the one I shipped, and it is the worst of the family, because "looks like plaintext" and "is plaintext" were being treated as the same statement on a column that exists to keep buyers' names and addresses from being readable.

There is also a subtler cost, the one that bites long after. A heuristic is not just a guess, it is a constraint on all future values. Once "starts with {" means legacy, no future version of the format may ever start with {. You have spent a byte of design space without noticing, and you will notice the day you want to store something that starts with {.

The window closes when the first row is written

Here is the asymmetry that makes this worth a post.

Adding a version marker to an empty column costs seven bytes and about four minutes. Adding one to a column with a million rows costs a migration that must read values written without a marker, which means the migration needs a heuristic, which is the very thing you were trying to get rid of. You do not escape the guess, you only get to bury it in a one-off script instead of the read path, and you get to keep it in the read path anyway until the backfill is provably complete.

So the marker is free exactly once, and the free moment is the moment the column is empty. Which is also the moment when you are most certain you will never need it, because there is only one format and it is obviously the right one. Every ambiguous storage format I have ever met was created by a competent person on the day it was cheapest to prevent.

My table had five rows. That is the only reason this post describes a fix rather than a permanent scar. If it had held a million, the honest advice would have been the opposite of what follows: keep the heuristic, document it as load-bearing, and write the version prefix only into new values, carrying both paths for years.

What the fix looks like

The value stored is now an envelope, and the envelope is three fields that each earn their place:

enc:v1:k1:<base64 nonce + ciphertext>

enc:v1: is the format version. k1 is the key identifier. The payload is the payload. Written out as PHP, the read path stops asking the value what it is:

public function convertToPHPValue($value, AbstractPlatform $platform): ?array
{
    if (!\is_string($value) || '' === $value) {
        return null;
    }

    if (!CipherEnvelope::isEnveloped($value)) {
        // Fail closed: a readable row is a bug or an intrusion, never a fallback.
        throw new \RuntimeException('This value is not in the "'.self::PREFIX.'" envelope.');
    }

    [$keyId, $ciphertext] = CipherEnvelope::split($value);

    return $this->decode(self::keyring()->get($keyId)->decrypt($ciphertext));
}

Three consequences follow, and only the first one is obvious.

Reading fails closed

There is no longer a branch that returns plaintext. A row that does not carry the envelope stops the application instead of quietly serving personal data in clear.

That is a real cost, paid at the worst moment: restore a pre-migration backup and the app breaks rather than degrades. I want that trade on this column, because the failure mode it replaces is silent. As a general rule for anything with a security dimension: when a read path has two branches and one of them hands back the unprotected version, the branch is the vulnerability, no matter how carefully the condition is written.

The key identifier makes rotation real

The previous post admitted, in as many words, that key rotation was not implemented and probably never would be, because rotating means holding two keys at once and the ciphertext carried no way to say which one produced it.

Once the identifier is in the envelope, rotation stops being a flag day and becomes three ordinary steps: promote a new active key while the old one stays in the keyring as read-only, backfill in the background, then drop the old key. Nothing has to happen atomically, and the day a key is retired too early, the failure is a message naming the missing key identifier instead of an authentication error you have to reverse-engineer.

/** @throws \RuntimeException when a stored value names a key we no longer hold */
public function get(string $id): TokenCipher
{
    return $this->ciphers[$id]
        ?? throw new \RuntimeException(\sprintf('This value was encrypted with key "%s", which is not in the keyring.', $id));
}

Note what happened there: a format decision bought back a capability. Seven bytes plus an identifier turned "we cannot rotate keys" into "we can rotate keys during business hours". That is the usual shape of this trade, and it is why the version prefix is not speculative generality. It does not anticipate a feature, it preserves the right to have one.

One detail worth stealing: the identifier that comes out of the database is validated against /^[A-Za-z0-9_-]{1,32}$/ before it is used or logged. It is attacker-influenced data on the day the threat model says the database is the thing you lost, and it ends up in exception messages.

The backfill does not guess either

The conversion command reads pre-envelope values by attempting decryption first, with every key in the keyring, and only treating the value as plain JSON if all of them fail:

foreach (EncryptedJsonType::keyring()->all() as $cipher) {
    try {
        return $this->decode($cipher->decrypt($stored));
    } catch (\Throwable) {
        // Not this key, or not a ciphertext at all: try the next one.
    }
}

// Nothing decrypted it: it can only be a value from before encryption.
try {
    return $this->decode($stored);
} catch (\Throwable) {
    return null;
}

This ordering is not stylistic. Base64-decoding {"name":"Ada"} fails outright, so plaintext can never be mistaken for ciphertext, while the reverse test (does it look like JSON?) has no such guarantee. When you must disambiguate, prefer the test that fails for structural reasons over the test that inspects appearances.

And because the type now refuses anything unenveloped, the same command doubles as the answer to "is the database fully converted?":

bin/console app:encrypt-buyers --dry-run

exits non-zero as long as one row is outside the envelope. That is a cron job and an alert, rather than a paragraph in a runbook that nobody reads after the deploy.

Where else the seven bytes apply

Encryption made this vivid, but the column was not special. Anything that outlives the process that wrote it is a format, and deserves a version:

Serialized columns. A json column holding a value object is a format the moment the object gains or loses a field. Version it, or you will be reading array_key_exists archaeology in two years.
Cache payloads. On disk, in Redis, anywhere. The classic failure is a deploy that changes a cached structure and reads yesterday's shape for the ten minutes before the cache turns over. A version in the key is the cheapest variant: old shape, old key, no reader ever sees it.
Queue messages. During a rolling deploy, two versions of the consumer run at once, by design. The message on the wire is a format shared between two codebases that happen to be the same repository at different commits.
Public identifiers. Anything you print on an invoice, put in a URL, or let a customer paste into a support ticket has escaped your control permanently. A one-character prefix (inv_, cus_, the whole Stripe convention) is the same seven bytes wearing a different hat, and it also makes a leaked identifier greppable.
Exported files. A CSV whose column order is the contract, because someone built a spreadsheet on top of it.

The test I now apply, and it takes one second: will this value be read by code I have not written yet? If yes, it needs to say what it is. Not because I expect to change it, but because "I will never need to change this" is a prediction about the future, and the version prefix is the cheapest insurance ever written against being wrong about one.

Is this not YAGNI?

The objection deserves a straight answer, because "you are not going to need it" is usually right and I use it constantly.

YAGNI is a rule about code, and it works because code is deletable. Write the abstraction you do not need, discover it, delete it: the cost of being wrong is bounded and it is paid by one person in one afternoon.

Formats break the assumption the rule stands on. You cannot delete a format that is already in the database, because you do not own all of its copies: some are in backups, some in a partner's system, some in a CSV a customer downloaded last March. The cost of being wrong is unbounded and it is paid by whoever is on call. When the cost of being wrong is asymmetric by three orders of magnitude, the cheap option is not the smaller diff.

What it actually cost

Eighty lines, tests included, and two hours. A prefix constant, a small class that wraps and splits the envelope, a keyring with one active key and any number of retired ones, a read path that throws instead of falling back, and a backfill command that tries decryption before it tries trust.

The part I keep thinking about is that none of it came out of a threat model, a checklist, or a review. It came from someone reading a public post carefully enough to notice that a condition was doing more work than it looked like. If you write technical posts and treat the comments as the part that comes after the work, that is backwards: the objection is the work, and it is the only free code review you will ever be offered.

The code above lives in InvoiceAnvil, a Shopify app that issues compliant invoices, built on ShipAnvil, the Symfony kit that ships the auth, billing, admin and deploy pipeline these apps stand on. The post that started this one is encrypting personal data at rest in Symfony, and the foundations are in deploying Symfony to a production VPS.

https://shipanvil.com/blog/storage-format-cannot-refactor

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Six decisions behind a shared-expense app, and the one where you must refuse to round

Eric Mollenthiel — Thu, 13 Aug 2026 13:00:39 +0000

Splitting one bill is a division. Settling a group of five people over three weeks of shared expenses is a different problem, and it is the one that actually has edge cases.

I have been building Kotisso, a shared expense tracker. The money side of it turned out to be far less about UI than about a handful of decisions that are cheap on day one and expensive to retrofit. This is the list I wish I had started from.

(One decision is missing here because it already has its own post: who gets the indivisible cent when you split 10 EUR three ways. That is the largest remainder method and the tiebreak everyone forgets. Everything below assumes you got that part right.)

The invariant that makes everything testable

Start from one property and refuse to break it:

In any group, the sum of all balances is always exactly zero.

A balance is what a person is owed. It is paid - owed + sent - received: what they advanced, minus what is theirs to bear, plus reimbursements they sent, minus reimbursements they received. Every unit of money entering a group is advanced by exactly one person and borne by one or more people, so the positives and the negatives cancel.

That single line gives you a free assertion after every write:

public function isConsistent(array $balances): bool
{
    $sum = 0;
    foreach ($balances as $balance) {
        $sum += $balance->getBalanceCents();
    }

    return 0 === $sum;
}

Every accounting bug I hit in the first month showed up as a non-zero sum before it ever showed up on a screen. A share attached to the wrong member, a deleted expense whose shares survived, a settlement counted on one side only: all of them break the invariant, none of them break the layout. That is why you find them with an assertion and not with your eyes.

Store hundredths even for currencies that have none

Integer cents, never floats. That part is well known. The part that is not:

1500 JPY is stored as 150000. The yen has no decimal places, so this looks like pure waste. It is what lets a single integer travel through the splitter, the balance calculator, the settlement planner, the CSV exporter and the PDF renderer without any of them needing to know which currency it carries. Exactly one place in the codebase knows that JPY has zero decimals: the formatter at the very end, and it learns it from ICU rather than from a table I maintain.

The alternative, letting the scale vary with the currency, means every arithmetic site becomes currency-aware. You will miss one.

Turning balances into transfers

You have balances that sum to zero. You want a small number of bank transfers that zeroes everybody out.

The exact minimum is NP-hard: it reduces to partitioning debtors into subsets that exactly match creditors. It is also irrelevant at these sizes. What people want is a plan that is short and obviously correct, and greedy gives that with a bound you can explain in one sentence.

// Both lists hold positive cents, sorted descending,
// with the member id as tiebreak so the plan is reproducible.
$transfers = [];
$i = 0;
$j = 0;

while ($i < count($debtors) && $j < count($creditors)) {
    $amount = min($debtors[$i]['cents'], $creditors[$j]['cents']);

    if ($amount > 0) {
        $transfers[] = new Transfer($debtors[$i]['member'], $creditors[$j]['member'], $amount);
        $debtors[$i]['cents'] -= $amount;
        $creditors[$j]['cents'] -= $amount;
    }

    if (0 === $debtors[$i]['cents'])   { $i++; }
    if (0 === $creditors[$j]['cents']) { $j++; }
}

Each iteration settles at least one person completely, so n members need at most n - 1 transfers. A flatshare of four ends up with three payments instead of the six that "everybody pays everybody back" produces.

Two details worth keeping. The two ifs at the end are independent, not an if/else: when a debtor and a creditor match exactly, both are finished, and advancing only one index leaves a zero-cent entry the loop then has to step over. And the descending sort needs a deterministic tiebreak, or two calls on the same data propose two different plans and the user watches the suggestion move around under them.

The mode where you must refuse rather than fix

Four split modes: equally, by shares, by percentage, and by exact amounts. The first three are proportional. The fourth is a trap.

In exact-amounts mode the user types each person's share. If those shares do not add up to the expense total, the tempting move is to absorb the difference into the largest one. My code did that for a while. Then I did the arithmetic on a realistic case: a 240 EUR restaurant bill entered as exact amounts that fall 15 EUR short, and one person silently pays 15 EUR more than they agreed to, with nothing on screen saying so.

Now it returns 422 and names the gap. Whoever does not want to count to the cent has three other modes.

A rounding rule is acceptable when nobody chose the numbers. It is not acceptable when somebody did.

Freeze the exchange rate at entry

You are on holiday, you pay 1 200 THB, the group counts in euros. The obvious implementation calls a rate API.

Do not. A live rate means every balance in the group drifts every morning, so a settled trip un-settles itself and a debt someone already paid comes back at a different number. Store what was entered, the currency, and the rate that was applied, then convert once and never again. The card's real rate is never the ECB's anyway, so the field has to be editable regardless.

The downstream consequence is the good kind: amountCents holds the amount in the group's currency and nothing below the entry point knows a conversion ever happened. Balances, the invariant, the settlement plan, the exports, none of them were touched when multi-currency shipped.

A pending expense counts nowhere

Groups can require expenses to be approved by the people they concern. An expense that is awaiting approval, or disputed, is excluded entirely: from the balances, from the group total, from the per-category breakdown.

The tempting alternative is to count it as provisional and mark it visually. That keeps the invariant intact and makes every number on the page mean something slightly different from what it says. Excluding it in one place, at the top of the balance loop, is one continue and no ambiguity:

foreach ($group->getExpenses() as $expense) {
    if (!$expense->getStatus()->countsInBalances()) {
        continue;
    }
    // ...
}

And one thing that is not about money at all

A free plan shows fewer rows, never different numbers. Expenses outside the visible window still count in the balances, in the group total and in the category breakdown, and the export says in the file itself what it summarised rather than dropping it.

A truncated statement is a false statement, and an accounting tool that produces one is worth nothing. That rule cost more design time than the algorithms did.

The order that worked

Invariant first, integer cents second, splitter third, screens last. Each of those is a few hours at the start and a data migration later.

The long version of the balance calculation, written for people rather than developers, is here.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

A week is seven nights, not 168 hours: dates in a shared-custody calendar

Eric Mollenthiel — Wed, 12 Aug 2026 16:51:44 +0000

Add seven days to a timestamp and you get the same day next week. That holds right up until the last Sunday in October, when it quietly stops holding and nothing tells you.

I have been building Nestido, a planner for separated parents: who has the children, when, and where. The family declares its custody rhythm once (alternating weeks, 2-2-3, 5-2-2-5), the app predicts the calendar from it, and the parents only record the deviations. Symfony 8, PostgreSQL, one server.

From the outside it is a calendar with colours. From the inside it is date arithmetic with a domain that punishes you twice a year, in a way no user will ever report. Nobody files a bug that says "your daylight saving handling is off". They see a number that looks wrong, they say nothing, and they stop trusting the app.

Here are the five rules I ended up with. Every one of them exists because the obvious version was wrong.

1. The unit is the night, and a night is not a duration

The first instinct is to store intervals and divide by 24. It is wrong in both directions, and you can prove it without leaving your own timezone.

In Paris, 1 June 23:30 to 2 June 22:30 is twenty-three hours and it is one night. 1 June 00:30 to 1 June 23:30 is also twenty-three hours and it is zero nights: nobody slept anywhere new. Identical durations, different answers.

So the count is not a duration at all, it is a number of local midnights crossed:

public function nights(\DateTimeZone $zone): int
{
    $from = $this->startsAt->setTimezone($zone)->setTime(0, 0);
    $to   = $this->endsAt->setTimezone($zone)->setTime(0, 0);

    return (int) $from->diff($to)->days;
}

Truncate both ends to local midnight, then diff. days already accounts for the transitions, so the two cases that break the hour-based version come out right:

28 March 20:00 to 30 March 08:00 in Paris is 35 hours (the clocks jump forward). Two nights.
24 October 20:00 to 26 October 08:00 is 37 hours (the clocks fall back). Two nights.

Divide by 24 and you get 1 and 1. In spring you have just deleted a night from every family in the country, and the statistics screen, which is the whole reason the app exists, is quietly off by one for the rest of the year.

2. Do the arithmetic in the family's timezone, store the result in UTC

Everything in my database is UTC. That is the easy half, and it lulls you into doing the arithmetic in UTC too. That part is wrong.

A handover happens at 18:00 local. It happens at 18:00 in July and at 18:00 in November. If you add seven days to a UTC instant, you get the same UTC instant one week later, which is a different wall clock time on the other side of a transition:

$start = new DateTimeImmutable('2026-03-25 18:00', new DateTimeZone('Europe/Paris'));

$start->setTimezone(new DateTimeZone('UTC'))
      ->modify('+7 days');          // 1 April, 19:00 local. One hour late, forever.

The rule that survived contact with the domain: cycle boundaries are computed on local dates at the local switch time, and converted to UTC only at the very end.

private function boundary(\DateTimeImmutable $day): \DateTimeImmutable
{
    return $day
        ->setTime(intdiv($this->switchMinutes, 60), $this->switchMinutes % 60)
        ->setTimezone(new \DateTimeZone('UTC'));
}

The test that guards it is the clearest statement of the whole idea. Two consecutive weekly boundaries around the October change, stored as UTC instants:

self::assertSame('2026-10-23 16:00', $segments[0]->start->format('Y-m-d H:i'));
self::assertSame('2026-10-30 17:00', $segments[1]->start->format('Y-m-d H:i'));

Different UTC instants, one hour apart. Both are 18:00 in Paris. If your two boundaries have the same UTC time on either side of a transition, your handover has drifted, and it will drift again in March.

3. Never walk a calendar from midnight. Walk from noon.

To render a month you loop over days. The obvious loop starts at local midnight and adds one day at a time. It works everywhere in Europe and North America, which is exactly why it is dangerous: in some zones midnight does not exist.

Chile moves its clocks at midnight. So do a handful of others, and Brazil did until 2019. On the transition night, 00:00 is not a valid local time and PHP moves you to 01:00. From then on, the loop keeps that hour:

$c = new DateTimeImmutable('2026-09-04 00:00', new DateTimeZone('America/Santiago'));
for ($i = 0; $i < 5; $i++) {
    echo $c->format('Y-m-d H:i P'), "\n";
    $c = $c->modify('+1 day');
}

2026-09-04 00:00 -04:00
2026-09-05 00:00 -04:00
2026-09-06 01:00 -03:00   <- midnight does not exist here
2026-09-07 01:00 -03:00   <- and it never comes back
2026-09-08 01:00 -03:00

Every day after the transition now starts an hour late. A night recorded at 00:30 falls outside the day it belongs to, and the calendar cell for that day is empty while the previous one holds two.

The fix is one line and it is the least obvious line in the codebase:

$noon = $firstDay->setTimezone($zone)->setTime(12, 0);

for ($i = 0; $i < $length; $i++) {
    $days[] = $noon->modify('+' . $i . ' days')->setTime(0, 0);
}

Walk from noon, offset from a fixed origin rather than accumulating, then drop to midnight at the end. Noon is never skipped by a transition, offsetting from the origin means an error cannot compound, and the final setTime(0, 0) renormalises to a midnight that actually exists. The same trick guards the cycle anchor, for the same reason.

4. A date is not an instant, and the type system will not tell you

Three fields in the custody rule are days, not moments: the anchor date, the start date, the end date. They are Y-m-d, they have no time, and giving them one is how you lose a day.

They are stored at UTC midnight and read back by their Y-m-d only. In Symfony forms, the date field carries both model_timezone and view_timezone set to UTC:

->add('anchorDate', DateType::class, [
    'model_timezone' => 'UTC',
    'view_timezone'  => 'UTC',
])

Set only one and a plain round trip through the form, with no edit at all, walks the date back by a day for anyone west of Greenwich. Save the form twice, lose two days, and the whole predicted calendar shifts under a family that changed nothing.

The handover time gets the same treatment from the other direction: it is a smallint of minutes since midnight, not a time column. 18:00 is 1080. It is not an instant, it has no date, and there is no timezone to attach to it. A time column invites exactly the conversion that must never happen.

5. The one line that silently poisons all of the above

None of this holds if PHP disagrees with you about what timezone the database is speaking.

Doctrine's datetime_immutable type reads a timestamp column with PHP's default timezone. My server runs Europe/Paris. So a value written as UTC comes back as a Paris wall clock reading of the same digits, which is a different instant:

date_default_timezone_set('Europe/Paris');
$v = DateTimeImmutable::createFromFormat('Y-m-d H:i:s', '2026-08-12 23:30:00');

$v->format('Y-m-d H:i P');                          // 2026-08-12 23:30 +02:00
$v->setTimezone(new DateTimeZone('UTC'))->format(); // 2026-08-12 21:30 +00:00

Two hours early, on every single row, in summer only. A handover recorded at 00:30 UTC is read as 22:30 UTC the day before: the night lands on the wrong day and is credited to the wrong parent. Nothing throws. The tests pass, because the test environment happened to agree with itself.

So the kernel says it out loud, before anything else boots:

public function __construct(string $environment, bool $debug)
{
    date_default_timezone_set('UTC');

    parent::__construct($environment, $debug);
}

Display is the only place that leaves UTC, and it leaves for the family's timezone, not the server's.

How I know any of this holds

The three services that do the counting (the cycle, the timeline, the statistics) know nothing about Doctrine, entities or repositories. They take a list of durations, an anchor date, a switch time, a timezone, and they return values. No fixtures, no database, no HTTP.

That is not architectural taste. It is what makes the two properties worth asserting cheap enough to assert everywhere:

A week across a transition is still seven nights, and the handover is still 18:00 on both sides. One test, both directions, spring and autumn.
Regenerating the plan twice produces exactly the same plan. Cycle segments are always generated whole, never clipped to "now", so nothing shrinks by a sliver on each pass. The day this stops being true, the predicted calendar starts moving on its own.

An off-by-one in a date library shows up as a stack trace. An off-by-one in a custody calendar shows up as a parent driving to a school where nobody is waiting. Same bug class, very different failure mode, and it is the reason all of the above got written down instead of remembered.

The app is at nestido.com, and the reasoning behind the night as the unit of account is written up for parents rather than for developers in counting overnights without an argument.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Cloudflare was 403-ing ChatGPT, Perplexity and Claude on my site, and my logs never knew

Eric Mollenthiel — Sun, 09 Aug 2026 05:50:43 +0000

For three weeks I wrote content aimed squarely at answer engines. An llms.txt,
FAQPage JSON-LD on two pages, a comparison page built to be quotable, a "how it
works" page with HowTo markup. The site is a small dating app I run on my own
server, loviam.com, Symfony and PostgreSQL on a single
box behind Cloudflare.

Referrals stayed at zero. The only external referrer my analytics table had ever
recorded, over its whole history, was chatgpt.com: three visits, one day in
July, never seen again.

I assumed the content was not good enough. The robots had never read it.

The five minute probe that should have been the first thing I did

Nothing in my usual instruments could see the problem, so I stopped looking at
them and asked the site directly, once per user agent, at its real public
address:

for ua in \
  "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  "Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" \
  "Mozilla/5.0 (compatible; Claude-SearchBot/1.0; +claudebot@anthropic.com)" ; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -A "$ua" https://www.loviam.com/)
  echo "$code  $ua"
done

200  Googlebot
403  OAI-SearchBot
403  PerplexityBot
403  Claude-SearchBot

Same result for ChatGPT-User, Claude-User and MistralAI-User. Meanwhile
bingbot, DuckDuckBot, Applebot, YandexBot and an ordinary browser all
got a 200.

The 403 body was eight bytes long, blocked., with server: cloudflare in the
headers, and there was no matching line in the Apache access log. The refusal
happened at the edge. My origin never heard about it.

Why every instrument I had was blind to this

This is the part worth stealing, because the failure mode generalises.

Application logs cannot record a request that never arrives. Obvious once
said, easy to forget when you are grepping the access log for PerplexityBot
and concluding "it never came".

First party analytics is worse than blind, it is reassuring. My beacon fires
from the page. A robot that gets a 403 never gets the page, so it never appears,
so the dashboard looks exactly like "nobody is interested".

My deployment smoke tests talked to the wrong server. They run with
curl --resolve www.loviam.com:443:127.0.0.1, which is the right call for a
deployment gate: you want to test the code you just shipped, not the CDN cache.
But it means the whole test suite speaks to Apache directly and Cloudflare is
invisible to it by construction. Thirty-eight green checks, every deploy, on a
path no visitor uses.

And the managed robots.txt actively pointed the wrong way. Cloudflare
injects its own block above yours. Mine named GPTBot, ClaudeBot, CCBot,
Bytespider, Amazonbot, meta-externalagent, Google-Extended and
Applebot-Extended, all of them training crawlers. Blocking those is a
defensible editorial decision and I stand by it.

But the HTTP filter was blocking something else: the search and on-demand
reading robots, which were not named in that file at all. So a perfectly
obedient crawler read "you are allowed", requested the page, and got a 403. That
mismatch between the two settings is the tell. It is not a policy, it is a
misconfiguration, and reading either file alone will never show it to you.

The fix is one toggle, and it is not the one named after crawlers

Cloudflare dashboard, zone level: Security → Settings → Block AI bots.

Not "AI Crawl Control", which is where I looked first and where the interesting
per-crawler table lives. The switch that returns the 403 is the plain one in
Security Settings, and it treats "AI bot" as a single category: the crawler that
builds ChatGPT's search index and the crawler that scrapes you for training data
are the same thing to it, even though for a publisher they are close to
opposites. One sends you traffic. The other does not.

Also worth checking afterwards: the managed robots.txt block, so it does not
still name a robot you have just decided to let through.

The guard I put in, and why it is a timer and not a test

What broke here is not my code. It is an edge configuration that can change
without a deploy, from a dashboard, possibly by a provider default I never
chose. A test in CI would only prove it was fine at build time.

So it is a daily command instead, app:seo:check-crawlers, which:

probes the real public URL, through Cloudflare, never --resolve;
walks sixteen user agents in three families: search, answer engines, training;
checks two independent things per robot, the actual HTTP status and whether the served robots.txt names it in a Disallow, because those two disagreeing is the exact signature I missed;
keeps an ordinary browser user agent as a control, so that "the robots are blocked" is never confused with "the site is down";
fails for search and answer engines, and never for training crawlers, which stay blocked on purpose.

A systemd timer runs it every morning and mails me only on state change.
An alert that fires every day is an alert nobody reads.

The second thing Cloudflare was doing, which was worse

While I was in there, I checked what else the proxy changed about requests, and
found the site had been taking itself down for weeks.

Every request reached Apache carrying the IP of a Cloudflare relay.
mod_remoteip was loaded but never configured, so nothing restored the real
client address:

172.71.135.63 - - [25/Jul/2026:12:21:03 +0000] "GET /fr/ HTTP/2.0" 200 10399

fail2ban reads those logs. So fail2ban was banning Cloudflare's own relays.
Cloudflare could then no longer reach my origin, and served HTTP 521 to every
visitor routed through that relay. The correlation was exact, to the second:

18/07 14:50:39  fail2ban  [apache-auth] Ban 141.101.98.192   (a Cloudflare range)
18/07 14:50:39  uptime probe: DOWN (HTTP 521)
18/07 15:49     unban cascade
18/07 15:54:02  uptime probe: RECOVERED

Five episodes in one week, the longest 42 minutes. My apache-auth jail triggers
at maxretry = 2, and my staging host sits behind htpasswd and therefore
manufactures 401s: two fat-fingered logins behind a shared relay were enough to
take production down for everyone else behind it.

Two quieter casualties of the same root cause: every rate limiter keyed on
$request->getClientIp() was bucketing the entire planet into a handful of
relays, and the visitor hash behind my "unique visitors" number was hashing the
relay, not the visitor. The weekly figure I had been reading to judge growth was
not counting what I thought it counted.

The fix is to trust CF-Connecting-IP, but only when the request comes from a
published Cloudflare range. Without that restriction anyone could forge the
header and walk straight past your rate limiting and your bans. Second layer, as
a net: put those same ranges in fail2ban's ignoreip, so that if the first layer
ever stops working you ban nobody rather than banning your own CDN. Both files
are generated by a monthly script, because the ranges do move, and a frozen list
would quietly reopen the trap.

What I would tell myself in June

If something sits between your users and your server, test through it, with
the user agent of the thing you care about. Not from your laptop, not with
--resolve, not from the logs. The whole class of bug here is that the failure
happens in a place none of your instruments can observe, and every instrument
you own will report a calm, plausible, completely wrong "nobody came".

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

Splitting €10 three ways: the largest remainder method, and the tiebreak everyone forgets

Eric Mollenthiel — Fri, 07 Aug 2026 23:44:05 +0000

Split €10 three ways and you get €3.33, €3.33, €3.33. That is €9.99. One cent has gone missing, and you now have to decide, in code, who pays it.

It sounds like a rounding detail. It is not: it is the difference between an app whose numbers close and an app whose numbers almost close. I hit it while building an expense-sharing app, and the fix turned out to be a voting-theory algorithm from the 1790s.

The three wrong answers

Round each share and hope. round(1000 / 3) = 333 per person, 999 total. You are one cent short of the expense. Every balance downstream inherits that error, and it compounds: fifty three-way expenses and the group's books are off by fifty cents with no line item to point at.

Give the remainder to the largest share. This is the common fix, and it is fine at €10. It is not fine when the split is uneven. If someone entered exact amounts that do not add up to the total, "absorb the difference on the biggest share" silently decides that one person pays €15 more than they typed. Three cents of rounding go unnoticed. Fifteen euros go unnoticed too, right up until someone checks.

Use floats. 0.1 + 0.2 != 0.3. You know this. The whole domain is integer cents or nothing.

The right answer is a 1792 apportionment method

The problem (divide a whole number of indivisible units proportionally to weights) is the same problem as allocating seats in a parliament to parties by vote share. Alexander Hamilton proposed a solution for the US House of Representatives in 1792. It is called the largest remainder method, and it is three steps:

Compute each participant's exact (fractional) share.
Give everyone the floor of it.
Hand the leftover units, one each, to whoever has the largest fractional remainder.

For €10 among three people: exact share is 333.33 cents each, floor is 333, allocated is 999, one cent left over. All three remainders are 0.33, so one of them gets the extra cent: 334 / 333 / 333.

The sum is exactly 1000. Always. Not approximately.

Here is the core of it, in PHP, working entirely in integer cents:

/**
 * @param array<int, float> $weights  participant id => weight
 * @return array<int, int>            participant id => cents
 */
private function prorate(int $totalCents, array $weights): array
{
    $sum = array_sum($weights);
    if ($sum <= 0) {
        throw new \InvalidArgumentException('No shares to split.');
    }

    $amounts = [];
    $remainders = [];
    $allocated = 0;

    foreach ($weights as $id => $weight) {
        $exact = $totalCents * $weight / $sum;
        $floor = (int) floor($exact);

        $amounts[$id] = $floor;
        $remainders[$id] = $exact - $floor;
        $allocated += $floor;
    }

    $left = $totalCents - $allocated;

    if ($left > 0) {
        $order = array_keys($remainders);
        usort($order, static function ($a, $b) use ($remainders, $weights) {
            $cmp = $remainders[$b] <=> $remainders[$a];
            if ($cmp !== 0) {
                return $cmp;
            }
            $cmp = $weights[$b] <=> $weights[$a];

            return $cmp !== 0 ? $cmp : ($a <=> $b);
        });

        foreach (array_slice($order, 0, $left) as $id) {
            ++$amounts[$id];
        }
    }

    return $amounts;
}

$left is bounded by the number of participants minus one, so this is never more than a handful of increments.

The tiebreak is the part people skip

Look at the usort comparator. It does not stop at comparing remainders. When two remainders are equal, which is exactly what happens in the €10-among-three case and is the case you will hit most often, it falls through to the weight, and then to the participant id.

Without that fallback you have a non-deterministic split. PHP's usort is not stable across all inputs, and even a stable sort leaves you at the mercy of insertion order. The same expense, recalculated after an edit, can hand the cent to someone else. Balances shift by a cent for no visible reason. Someone notices, does not trust the app any more, and they are right not to.

So the rule is: the tiebreak chain must terminate in something total and immutable. The id works. "Whoever was added to the group first" works. "Whatever order the hash table gave me" does not.

What this buys you: an invariant you can assert

Once every split sums exactly to its expense, a much stronger property falls out of the model for free. Each participant's balance is:

balance = what they paid - what they owe + what they sent - what they received

Sum that across every member of a group and every term cancels: every euro paid is owed by someone, every transfer sent is received. The balances of a group always sum to exactly zero.

That is not a nice-to-have, it is a test oracle. It turns "did I get the money maths right" into a single assertion you can run after every operation:

public function testBalancesAlwaysSumToZero(): void
{
    $balances = $this->calculator->forGroup($group);

    self::assertSame(0, array_sum(array_map(
        static fn (Balance $b) => $b->cents(),
        $balances,
    )));
}

Any bug that loses or invents a cent anywhere trips this: a bad split, a mishandled refund, a currency conversion, a deleted participant. It is the cheapest high-value test in the codebase, and it only exists because the splitter is exact.

Three edge cases worth stealing

Negative totals. Refunds and corrections are negative expenses. floor(-333.33) is -334, not -333, so the remainder logic inverts and you over-allocate. Take the absolute value, split that, negate at the end. Two lines, and it stops a whole category of sign bugs.

Exact amounts should refuse, not repair. If a mode lets people type each share by hand and the total does not match, do not silently fix it. Reject the input and name the gap: "you entered €85.00, the expense is €100.00, €15.00 missing". Someone who does not want to do the arithmetic has the other modes. Someone who does want to do it deserves to be told they got it wrong rather than have it quietly rewritten.

Zero-decimal currencies. Store everything in hundredths regardless. ¥1,500 is 150000. Then one integer travels the entire calculation without ever needing to know what currency it is, and formatting stays a presentation concern where it belongs.

Where this came from

I ran into all of this building Kotisso, a shared-expense tracker for flatshares, group holidays and separated parents. The zero-sum invariant is the whole design: everything else in the app is arranged so that it cannot be violated.

The largest remainder method is old, well-studied, and takes about thirty lines. If you are dividing indivisible units by proportion anywhere (money, seats, inventory, rate limits) it is probably the algorithm you want, and the tiebreak is probably the part you are about to forget.

Written by Eric Mollenthiel, freelance Symfony developer in Lyon, France.
More at mollenthiel.fr.

DEV Community: Eric Mollenthiel

Symfony 7.4 to 8.1, measured twice a month apart: two of the scary parts were fixed in patch releases

The bench

Then and now

The failing test was a patch regression, and it was in 7.4 too

The 500s were a removed class, and 8.1.6 put a stub back

Deprecations: the count depends on whether the container is compiled in that run

What --with-all-dependencies brings that is not Symfony

What this does not measure

Postgres RLS in Symfony: a setup check for a missing FORCE, and two ways it says "nothing to report" without looking

The bench

The two queries

What they return

Route 1: the first query you would naturally write

A detour: the check that warns every install

Route 2: the connection, not the query

Where the check can live

What this does not cover

Reproduce it

Postgres RLS in Symfony: three green isolation tests, and the UPDATE that moves tenant 1's invoices into tenant 2's books

The loud error that gets you there

Three policies, three assertions, four writes

The two refusals on that row are not what they look like

The fourth assertion is one line, and it belongs in the same test

Seed with the context, not around it

Reproduce it

Postgres RLS in Symfony: with one tenant in the fixture, your isolation suite passes with no policy at all

The invariant is not "the owner run must fail"

Equality alone is green in three databases that are broken

Disjointness has to stay inside the boundary it is checking

The two ways "no tenant context" fails, and they are not alike

The leak that hides under PHP-FPM

Reproduce it

Row-level security in Symfony: the role that ran your migrations bypasses every policy you wrote

The setup, which is the one you would write

One line changes the answer

Why a Symfony project walks into this and a test suite does not catch it

Two fixes, and I measured both

FORCE ROW LEVEL SECURITY

A serving role that does not own anything

The guard that survives the next table

And once RLS does apply, the setting has two ways to be missing

What I would keep

Single-database multi-tenancy in Symfony: a 31-line Doctrine filter, and the five places it never runs

The filter

The layer that knows who is asking

Place 1: the console, and every Messenger worker

Place 2: your own back office, on purpose

Place 3: find() when the entity is already in the identity map

Place 4: DBAL, and every line of native SQL

Place 5: joined inheritance, when the column is not on the root table

And one place it does run, where most people assume it does not

Proving it, rather than believing it

What I would keep

Every no-code builder generates code. I shipped an interpreter instead.

The domain, in four lines

Why generating Java is the trap

What I shipped instead

The part I did not see coming: the grammar becomes data

The bill

Three things the interpreter forced me to get right

The obvious objection

Where it is

Your storage format is the one thing you cannot refactor

Code is soft, storage is not

Sniffing is the tax you pay for skipping the version

The window closes when the first row is written

What the fix looks like

Reading fails closed

The key identifier makes rotation real

The backfill does not guess either

Where else the seven bytes apply

Is this not YAGNI?

What it actually cost

Six decisions behind a shared-expense app, and the one where you must refuse to round

The invariant that makes everything testable

Store hundredths even for currencies that have none

Turning balances into transfers

The mode where you must refuse rather than fix

Freeze the exchange rate at entry

What `--with-all-dependencies` brings that is not Symfony

`FORCE ROW LEVEL SECURITY`

Place 3: `find()` when the entity is already in the identity map